Self-healing rules: automatic fixes

By default every self-healing fix waits for a person. A rule lets your project decide some of them without a review: apply the safe ones, insist on review for sensitive tests, or reject fixes you never want. Rules act only after a run has finished, never during one, and every decision they make is written to the audit trail.

A project starts with no rules, and with no rules nothing changes: runs file suggestions and people decide.

Open Self-healing → Rules. Everyone in the project can read the rules. An Admin or Test Manager can create, change, enable, disable and delete them.

What a rule says

A rule has a scope (which suggestions it looks at), conditions (which of those it matches), and an action.

Applies to

Field	Matches
All tests	Every test in the project. Not components (see below).
Tests	The tests you tick
Tags	Tests with any of these tags, e.g. `smoke, checkout`
Suites	Tests in any of these suites
Components	Steps inside these components

A component’s steps are shared by every test that calls it, so a fix to one changes tests the rule’s author may never have opened. A component step is only covered when the component is named here. All tests, tags and suites never reach into components.

When

Every condition must hold for the rule to match. They are checked against the evidence the run recorded with the suggestion.

Field	The suggestion must…
Healing tier	Come from at most this tier: Recorded fallbacks only (tier 0), Fallbacks and element matches (tier ≤ 1), or Any, including AI (tier 2)
Minimum confidence (%)	Have at least this confidence
Minimum lead (%)	Lead the runner-up by at least this much. Optional. A suggestion with no runner-up (a promoted fallback) has no measured lead, so a rule that asks for one does not match it.
Risk	Have one of the ticked risk classes
Step types	Be on one of the step types picked from the list, e.g. Click. Any step type means any.
Seen in at least (runs)	Have been found by this many separate runs. 2 or more means one flaky run cannot change a test.
Only when the run itself already acted on the healed element	Have been Healed during the run (not only suggested), so the run already proved the test passes with it

Action and mode

Action	What it does to a matching suggestion
Apply automatically	Applies the fix, exactly as an approval would
Always require review	Leaves it for a person, even if another rule would apply it
Reject automatically	Rejects it. Like a person’s rejection, the same fix is not suggested again for that step.

Mode
Dry run - only record what it would do	Changes nothing. Each match is written to the audit trail as would have applied (or rejected), and the suggestion stays pending for a person.
Active	The rule acts

Priority: lower runs first. It matters only between rules with the same action (see below). Enabled: a disabled rule is skipped as if it did not exist.

A fix to a Ready test

Automatic fixes are collected in one Draft revision rather than one revision per fixed step. The first fix opens it; every fix after that, from the same run or a later one, is added to it, and its history note lists each fix. Marking the Draft Ready closes it, so the next fix opens a new one. Each fix can still be reverted on its own: a revert puts back that step’s locator, wherever it now lives. A fix never changes a person’s own Draft revision; it opens a revision of its own next to it.

For a test that is Ready, the rule says what the fix becomes:

Setting	Result
Becomes a new Draft revision (default)	One Draft collects the fixes. Regression keeps running the Ready revision until someone marks the Draft Ready
Becomes the next Ready revision	Each fix is the next Ready revision, and regression picks it up straight away

A Deprecated test is never changed.

When rules overlap: the most cautious wins

Several rules can match the same suggestion. The result does not depend on which rule comes first. The most cautious action wins:

Always require review beats everything,
then Reject automatically,
then Apply automatically.

Priority only breaks the tie between matching rules with the same action (for example, which of two Apply rules is recorded as the one that applied the fix).

So a broad rule such as “apply low-risk fixes in all tests” can be made safe with a narrow one such as “always review tests tagged payments”. The narrow rule wins on payment tests whatever their priorities are. If no rule matches, a person reviews, as before.

Dry-run rules take no part in the real decision. The audit trail records what the outcome would have been with them switched on.

Limits no rule can lift

These are built in. A rule that tries to cross one is refused when you save it, and each is checked again for every suggestion:

Limit	Why
A high-risk step (delete, submit, pay, approve, password fields…) is never fixed automatically	A wrong fix there does harm, not just a failed run
An AI (tier 2) proposal is never fixed automatically	It is a judgement call, not a measured match
An automatic fix needs at least the confidence the runner itself needs to act on the step: 70% for low risk, 78% for medium	A rule cannot trust a match the run would not have used
At most a daily limit of automatic fixes per test in a rolling 24 hours (3 unless your organization or project changes it; see Daily limit)	A page changing that fast needs a person. Further fixes wait for review (too many automatic fixes on this test).
A component step needs its component named in the rule	See Applies to
A fix whose decision cannot be written to the audit trail is not applied	An unexplained change to a test is worse than a suggestion that waits
A fix for a step edited around its locator since the run is not applied	The rule vouched for the step as the run saw it. See When the test changed since the run.

Other edits to the test do not hold a fix back. If someone saved the test after the run, but this step’s action, value, options and place are as they were, a rule applies the fix to the test as it is now, on top of their save. The fix itself is the same either way. If the page now reaches that step differently and the fix turns out wrong, the rule’s usual safety nets apply: if the fixed step fails again in a later run, the rule pauses for that test, and reverting the fix pauses it for that step (see Paused rules).

Always require review and Reject automatically rules are not limited by risk or tier: insisting on a person, or saying no, cannot make a test worse.

Daily limit

How many automatic fixes one test may get in a rolling 24 hours, all rules together. A fix counts until a day after it was made; fixes a person approves never count.

Level	Setting	Who changes it	Where
Organization	Default for its projects, and the most a project may set	Organization administrator	Organization → Settings, card Self-healing · daily limit
Project	Its own limit, from 0 up to the organization’s maximum	Anyone who may manage rules	Self-healing → Rules, line at the top → Change
System	Default 3, and no setting above 50	-	-

A project without its own limit uses the organization’s default. 0 switches automatic fixes off for the project: every fix waits for a person. If an organization lowers its maximum below a project’s own limit, the project is held to the maximum, and gets its own limit back if the maximum rises again.

Every change is in the project’s audit trail under Rule changes (Daily limit changed), with the limit before and after. A fix held back by the limit says which setting held it, e.g. limit 5 per test in 24 hours, set by the organization’s default.

How healing ranks candidates

When a step’s locators find nothing, healing scores the elements on the page against the step’s last known good fingerprint (see How a heal is found). Two settings shape that, both on Self-healing → Rules, in the card under the daily limit:

A preset per application decides which signals count most:

Preset	For
Balanced (default)	Most applications: stable ids and test hooks count most, then the name and label
Generated ids	Applications that generate ids and classes (Maximo, Salesforce, ExtJS): the label, heading and table row count more than the id
Test hooks	Applications with `data-testid` (or similar) on every control: a matching hook decides
Dense grids	Screens with many look-alike controls in rows: the row and section count more. Pair it with a higher margin

A run uses the preset of its environment’s application. Without one, a project with a single application uses that application’s preset, and any other run uses Balanced.

The project’s thresholds decide what a run does with the best candidate:

Threshold	Default	Range
Act on a low-risk step from	70%	60% to 99%
Act on a medium-risk step from	78%	60% to 99%, never below the low-risk bar
Lead over the next candidate	12%	5% to 50%
Suggest from	50%	30% to 90%, never above the low-risk bar

Changing either takes permission to manage rules. Every change is in the audit trail under Rule changes (Healing ranking changed), and every heal’s report names the preset it was ranked with, plus the thresholds when the project set its own.

Preview before you change

Neither change is saved blind. Picking another preset for an application shows what it would have done before Use … saves it, and in the thresholds dialog Save waits until you Preview against history. The preview replays every heal of the last 30 days from the evidence the run recorded, with the settings as they are and as proposed:

It says	Meaning
would have picked a different element	The change hands the heal to another candidate on the page: a fix for a different element. Shown first, with the steps it affects. Read this before anything else
acted on during the run → only suggested (or the reverse)	Same element, decided differently
Your rules would decide … differently	A rule’s conditions (such as confidence at least 85%) now meet, or miss, a heal they did not before
compared on its recorded lead	A heal recorded before runs kept the next candidates’ scores: its lead over them cannot be re-scored, so the recorded one is used

A preset is previewed against its own application’s heals only. Tier 0 heals (a fallback locator that worked) do not depend on weights or thresholds and are not replayed. Nothing is saved by previewing, and anyone in the project may preview.

Your organization’s own profiles and minimums

An organization administrator manages two more settings under Organization → Projects, in the card Self-healing · how candidates are ranked:

Profiles of your own. Start from a preset, then set each signal’s weight from 0 to 5. The signals are grouped by what they say about an element: what it is known by (test hook, id, name, label, text…), what kind it is (role, tag…) and where it sits (heading, table row, position…). Whatever you set, what an element is known by must carry at least 50% of the weight, so where an element sits can never outvote what it is. A saved profile appears under Your organization in every project’s picker, and each change gets a new version, which heal reports name.

Editing a profile in use changes how the next runs of every application using it heal, across projects. So Save waits for Preview against history, which replays those applications’ recent heals with the new weights. Its examples name the project and step, not the test.
A profile in use cannot be deleted. The message names the applications that use it; choose another profile for them first.
Suggest from review decisions proposes weights from the heals people approved, rejected or reverted across the organization (rule decisions do not count). It needs at least 20 decisions, 5 of each kind, and proposes only. Check the highlighted changes and preview them like any other.

Minimum thresholds. The least each threshold may be in any project. A project already set below a new minimum is held to it, and its card says so. Its own setting is kept, so lowering the minimum again gives it back. The minimums for acting on a low- and medium-risk step bind rules too: no rule fixes a test without review below them. Each project’s audit trail records how its thresholds moved.

Some limits no setting reaches: a high-risk step never acts on a healed element, a match on position alone is never applied, and a rule never fixes a test without review below the default bars (70% low, 78% medium). A lower project threshold lets a run carry on with a heal sooner; the fix itself still waits for a person or a rule that meets the default bar.

Paused rules

A rule pauses itself where it has been wrong:

When	What pauses	Shown as
A step the rule fixed fails again (or needs healing again) in a later run that used the fix	The rule, for that whole test	tripped on the dashboard: “a step it fixed failed again”
A person reverts the rule’s fix (unless they untick Pause the rule for this step)	The rule, for that one step (for a component step: that step of the component, whichever test finds it)	paused: “… reverted its fix”

While paused, the rule’s fixes there wait for review. Everything else it covers is unaffected. A pause lasts until an Admin or Test Manager chooses Let it fix again under Paused for a test on the Rules view. Paused rules also appear as an alert on the dashboard.

Preview against history

Preview against history puts the last 30 days of the project’s suggestions through the rules, using the same engine a run uses, and shows for each rule how many it would have applied, rejected or left for review, and how many a guardrail would have held back. It also shows a few examples and what actually happened to them. The daily limit and paused rules are not part of the preview.

You can preview a rule while editing it, before saving. The preview treats every rule as enabled and active, so it shows what switching it on would really do. It also shows the total for all the rules together. That can be less than the sum of the rules, because a require review rule always wins.

Previewing changes nothing, and anyone in the project can do it.

Rolling out rules

We recommend this order:

Start in dry run. Create the rule with Mode: Dry run. It records what it would have done and changes nothing.
Check the preview and the trail. Use Preview against history, and after a few runs look at the Held back view of the audit trail for would have applied entries. Would you have approved each of those fixes?
Start narrow and strict. A small scope (one suite or tag), low risk only, Seen in at least 2 runs, and Only when the run itself already acted on the healed element.
Switch to Active once the numbers look right, and add Always require review rules for areas that must always have a person.
Watch the dashboard. It counts automatic fixes this week and how many were reverted, and it alerts on every paused rule.

What a rule records

Once a project has an enabled rule, every suggestion a run files gets a Rules checked entry in the audit trail. It holds the verdict and, under Evidence, every condition of the deciding rule, passed or failed: for example confidence 83% ≥ 80% ✓ and occurrences 1 < 2 ✗. If no rule matched, it says so.

A card on the Suggestions view names the rule that applied or rejected it, with the rule’s version. When a fix was held back for any other reason than “no rule matched” or “a rule requires review”, the trail adds a Left for review entry that says why:

Not applied:	Meaning
the rule is in dry-run mode	A dry-run rule matched. The entry says what it would have done.
a guardrail forbids fixing it automatically	High risk, AI tier, or confidence below the runner’s bar
too many automatic fixes on this test in 24 hours	The daily limit was reached
the rule is paused for this test	See Paused rules
the step changed before the fix could be applied	Someone changed the step’s locator. The suggestion moves to No longer applies.
the step was changed since the run that found the fix	Someone edited the step around its locator (its action, value or options, or moved it into another block) after the run started. A rule only vouches for the step it saw, so the fix waits for a person. See When the test changed since the run.
someone was editing the test	Someone held the test’s edit lock. The fix waits in the editor’s banner, and a later run applies it once nobody is editing.
the test is deprecated	Deprecated tests are never changed
the audit trail could not be written	The fix was held back rather than applied without a record
an error occurred	Something failed while applying it. The run’s result is unaffected, and the error is in the entry’s evidence.

A revision a rule made shows the rule’s name and version as its author in the test’s History, and the new locator is stamped auto-heal.

Editing or deleting a rule never undoes fixes it already made. Every save creates a new rule version, and the audit trail keeps each version as it was, so an entry from before the edit still shows the rule that actually made the decision. If two people edit the same rule at once, the second save is refused and asks them to reload.