Note:
Auto-heal is currently a Beta feature. For more information, contact support@whatfix.com.
Auto-heal is supported for Flows, Smart Tips, Beacons, Launchers, Blockers, and User Actions.
Overview
Applications continuously evolve through feature releases, UI updates, and design changes. While these updates may not noticeably change the user experience, they can modify the underlying elements that Whatfix content is associated with.
For example, a button may continue to appear in the same location and serve the same purpose, but changes to its HTML attributes, page structure, or metadata can prevent Whatfix from identifying it as the originally configured element. When this happens, attached content such as Flows, Smart Tips, Beacons, Launchers, Blockers, or User Actions may not appear or behave as expected. These issues are commonly referred to as element detection failures.
Previously, resolving these failures required content authors to manually investigate the issue, locate the affected element, reselect it, and republish the content. This process can be time-consuming, especially when application updates affect multiple pieces of content.
Auto-heal helps reduce this maintenance effort by automatically identifying and repairing eligible element detection failures during runtime. Once a failure is detected in production, Auto-heal repairs are applied automatically on the end-user side without requiring content authors to update content, reselect elements, or republish.
What Is Auto-heal?
Auto-heal is an AI-powered capability that automatically repairs element detection failures in Whatfix content.
When Whatfix cannot locate the target element associated with the content during runtime, Auto-heal attempts to identify the intended element and restore the content experience. No content updates, element reselection, or republishing actions are required from the author.
By automatically recovering from common application changes, Auto-heal helps authors spend less time maintaining content while reducing disruptions for end users.
How does Auto-heal Work?
Auto-heal is automatically triggered when Whatfix cannot locate the target element associated with supported content. The following example illustrates how the healing process works.
Example:
Consider a Flow step that guides users to click a Submit Request button.
After an application update, the button continues to appear in the same location and perform the same action. However, the application's underlying HTML attributes have changed.
As a result, Whatfix can no longer identify the original target element, causing the Flow step to fail.
When this occurs in production, Auto-heal automatically begins the healing process during runtime without requiring any action from the content author.
Auto-heal detects that the Flow step cannot locate its configured target element.
It captures contextual information about the current page, including page structure, application metadata, DOM context, screenshots, and screenshots.
The runtime information is compared against the element information originally captured during authoring to identify what has changed and determine the most likely replacement element.
Vision-based AI analyzes the captured information and compares the original target element with the current state of the application.
Rather than relying on a single HTML attribute, Auto-heal evaluates multiple signals, including visual appearance, surrounding page context, element relationships, and structural similarities.
If Auto-heal identifies a replacement element with sufficient confidence, it generates updated, relevant metadata and stores it in a separate runtime layer.
Once the corrected metadata is stored, the repair is automatically applied for all subsequent users who encounter the same Flow step.
Note:
The healing process begins only after a failure is detected. As a result, the first user who encounters the issue may still experience the failure. Once the healing process is complete, all subsequent users automatically receive the corrected experience.
Info:
When Auto-heal chooses not to Heal
Auto-heal is designed not only to repair failures but also to avoid making incorrect repairs.
If Auto-heal cannot identify a replacement element with sufficient confidence, no repair is applied. Instead, the content continues to behave as originally configured.
This confidence-based approach helps prevent incorrect element matches and reduces the risk of unintended behavior. As a result, authors can trust that Auto-heal attempts repairs only when a high-confidence match is identified and avoids making speculative or potentially inaccurate changes.
How does Auto-heal protect customer data?
Auto-heal includes built-in privacy and security controls designed to protect customer data throughout the healing process.
HTML-level PII masking: Sensitive information present within page markup is masked before processing. This helps prevent personally identifiable information (PII) contained within the application's DOM structure from being analyzed.
Screenshot-level PII masking: Auto-heal applies screenshot-level masking to help protect sensitive information that may appear within captured page screenshots.
Content integrity protection: Auto-heal does not modify published content. Instead, healed metadata are stored in a separate runtime layer and applied dynamically when content is rendered.
As a result:
Authoring workflows remain unchanged.
Review and approval processes remain unchanged.
Existing publishing workflows continue to operate normally.
Original content remains intact.
What are the benefits of Auto-heal?
For End Users
Reduces disruptions caused by application updates.
Improves the reliability of guided experiences.
Automatically applies repairs when a high-confidence match is identified.
Minimizes instances where content fails to appear because of element changes.
For Content Authors
Reduces manual troubleshooting and maintenance effort.
Minimizes the need for element reselection.
Helps content recover more quickly from UI and HTML changes.
Reduces the operational impact of application upgrades.
Known Limitations
Auto-heal currently supports only element detection failures and has the following limitations:
iFrame support: Auto-heal does not support content rendered inside iFrames.
First-user impact: The first user who encounters a failure may still experience the issue before healing is completed.
Non-element failures: Auto-heal does not repair failures unrelated to element detection. For example, Auto-heal does not repair Smart Context failures, auto-tagging failures, or other issues where content behavior is affected by factors other than target element identification.
Deployment: Auto-heal is not supported for customers using self-hosted or on-premise deployment.