This article covers the most common scenario in which an automation rule appears to have fired successfully but the target case fields do not reflect any changes. It explains how the rule execution chain works and provides a structured set of checks to complete before raising a Support case.
How case field population from automation rules works
When an automation rule is triggered, the following sequence occurs:
Trigger event. A form is submitted or a case field is updated, matching the rule's trigger configuration.
Condition check. If the rule has criteria (for example, only trigger if Field X equals a specific value), those criteria are evaluated. If the criteria are not met, the rule does not execute.
Action execution. If the 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 case field.
Delay handling. If the action has a delay configured, it is queued as an in-flight rule rather than executing immediately. It will run at the scheduled time.
A case field will not update if any step in this chain fails or does not resolve correctly. The most common failure point is step 3 — the token in the field mapping references a form component or case field that no longer exists or has been renamed.
Self-diagnostic steps
Work through these checks in order before raising a support case.
Step 1 - Confirm the rule actually triggered. Go to Configuration > Services > Automation and open the relevant rule. Check the rule history or log to confirm it triggered for the form submission in question. If there is no trigger event recorded, the rule did not fire at all. This means the trigger condition was not met — check 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 of the same form. If the rule has criteria (a conditional filter on the trigger), verify that 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 target field uses a token to source its value — for example, ${form_component_45}. If the form has been edited since this rule was created and the component referenced by the token was renamed or removed, the token will not resolve and the field will not be updated. Check that every token in the action references a component that currently exists on the form. You can verify component IDs by opening the form in Configuration > Forms and inspecting each field's settings.
Step 4 - Check whether the action has a delay. If the rule action has a delay setting (for example, form submitted date +14d), the case field update is queued and will not run until the delay period has elapsed. This is correct behaviour, not a failure. If the delay is not intended, edit the rule and remove the delay from the action.
Step 5 - Check the Override inflight rules setting. If a delayed action from a previous submission is still in flight (queued and waiting to run), and the form is resubmitted, the new trigger may not execute correctly unless Override inflight rules is enabled. If case fields are not updating on resubmission, enable this setting on the rule and test again.
Step 6 - Check whether the form was updated after the rule was configured. If the form structure changed after the automation rule was built, the field version the rule expects may no longer match the live form. This is a common cause of silent failures. Any time a form is edited and republished, the automation rules referencing it should be reviewed to confirm the component IDs and token references are still valid.
Understanding in-flight rules
An in-flight rule is an automation action that has been triggered but has a delay before it executes. For example, an email or a case field update configured to run 14 days after form submission is an in-flight rule.
In-flight rules are queued on the server. They will execute at the scheduled time as long as the original trigger conditions remain valid. If the form or the case is deleted before the delay expires, the in-flight action will not execute.
If multiple submissions of the same form generate multiple in-flight rules, the Override inflight rules setting controls what happens. If the setting is enabled, a new submission replaces the in-flight rule from the previous submission. If the setting is disabled, both in-flight actions remain queued and both will execute at their respective scheduled times.
When to raise a Support case
If you have completed all of the checks above and case fields are still not updating, raise a support 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 been updated and what value was expected
The date and time of the form submission that triggered the rule
Whether the form has been edited since the rule was created
The result of your check in step 1 above (whether the rule history shows a trigger event)