When an automation rule fires but a case field does not update, the cause is almost always in the rule's trigger conditions, field mapping, or delay configuration. Work through the steps below to identify and fix the issue before raising a Support case.
How case field population works
When an automation rule triggers, the following sequence runs:
A form is submitted or a case field is updated, matching the rule's trigger configuration.
If the rule has criteria, those criteria are evaluated. If they are not met, the rule does not execute.
If criteria are met (or no criteria are set), the configured actions run. For an Update Case Field action, the system resolves the token value and writes it to the specified field.
If the action has a delay, it is queued as an in-flight rule and runs at the scheduled time.
The most common failure point is step 3 — the token in the field mapping references a form component that no longer exists or has been renamed.
Diagnostic steps
Work through these checks in order.
Step 1 — Confirm the rule triggered. Go to Configuration > Services > Automation and open the relevant rule. Check the rule history to confirm it triggered for the form submission in question. If no trigger event is recorded, the rule did not fire — move to step 2. If a trigger event is recorded, move to step 3.
Step 2 — Check the trigger condition. If the rule uses Trigger only on initial form submission, it will not fire on subsequent submissions. If the rule has criteria, verify the form submission met those criteria. If the criteria were not met, the rule is working as intended.
Step 3 — Check the field mapping. Open the rule and review the Update Case Field action. Each mapped field uses a token to source its value, for example ${form_component_45}. If the form has been edited and the component referenced by that token was renamed or removed, the token will not resolve and the field will not update. Verify component IDs by opening the form in Configuration > Forms and inspecting each field's settings.
Step 4 — Check for a delay on the action. If the rule action has a delay configured, for example form submitted date +14d, the case field update is queued and will not run until the delay has elapsed. If the delay is not intended, edit the rule and remove it.
Step 5 — Check the Override inflight rules setting. If a delayed action from a previous submission is still queued and the form is resubmitted, the new trigger may not execute correctly unless Override inflight rules is enabled.
⚠️ Warning: If Override inflight rules is disabled and multiple submissions occur, both queued actions will execute at their respective scheduled times. This can result in case fields being overwritten by an older submission's values. Enable this setting if you expect forms to be resubmitted before a delay expires.
Step 6 — Check whether the form was edited after the rule was built. If the form structure changed after the automation rule was configured, component IDs or token references may no longer be valid. Review all token references in the rule against the current form and update as needed.
In-flight rules
An in-flight rule is an automation action that has been triggered but has a delay before it executes. A case field update configured to run 14 days after form submission, for example, is an in-flight rule.
In-flight rules are queued on the server and execute at the scheduled time, provided the original trigger conditions remain valid. If the form or case is deleted before the delay expires, the in-flight action will not execute.
The Override inflight rules setting controls what happens when multiple submissions of the same form generate multiple in-flight rules. If enabled, a new submission replaces the queued rule from the previous submission. If disabled, both actions remain queued and both will execute.
Raise a Support case
If you have completed all of the checks above and case fields are still not updating, raise a case via the Access Digital Assistant. Include the following:
The automation rule name.
The service and form the rule is configured against.
The case field that should have updated and the expected value.
The date and time of the form submission.
Whether the form has been edited since the rule was created.
The result of step 1 above — whether the rule history shows a trigger event.