Post-Action Validations#
Post-Action Validations are checks that run after an Automation Scheduled Action task is completed to confirm that the action worked as expected.
Post-Action Validations define what success looks like after the task is completed.
A Scheduled Action can have one or more Post-Action Validations configured, or none at all. When no validations are configured, the task is marked as Processed as soon as it completes.
How It Works#
Once the ASA task action is done, the task enters the validation phase:
- Each configured Post-Action Validation runs, in order, against that task.
- All configured validations must pass for the task to be considered successful. This step returns:
True- if all the validations pass, the task is marked asProcessed.False- if any of the validations failed, or an error occurred during validation, the task is marked asFailed.
A failure on one task does not affect other tasks from the same Scheduled Action.
Post-Action Validation Options#
You can add multiple validations checks to the Automation Scheduled Action and they are evaluated in the order you define them. Currently, the following types are supported:
Checks whether the Automation Controller Instance comes back online within a set time after the action runs.
You must specify the expected time in seconds.
Ideal for:
- Confirming that a version update or manager change completed and the instance is back up.
- Catching cases where a new instance fails to start or takes too long to recover.
Remarks:
- The instance is considered started when the system reports its runtime state as
Running. - No end-to-end connectivity check is performed, only the runtime state is checked.
Result:
- Returns
Trueif the instance reaches aRunningstate within the configured time. - Returns
Falseif the instance does not start in time, and the task is marked asFailed.
Runs a DEE action to check whether the action produced the expected result. The DEE action returns the validation decision.
Ideal for:
- Custom validation logic not covered by the built-in validation types.
- Validation that depends on external systems or business-specific criteria.
You must specify the DEE action to use. Make sure its inputs and outputs match the DEE contract:
| Direction | Key Name | Data Type | Description |
|---|---|---|---|
| Input | Task | AutomationScheduledActionTask | Provides context about the current task being validated. |
| Output | Result | Boolean | Determines the outcome. true = Pass, false = Fail. |
Table 1: Post-Action Validation DEE Contract
Result:
- Returns
Trueif the DEE action is successful The task is marked asProcessed. - Returns
Falseif the DEE action fails or throws an error. The task is marked asFailed.
A failed validation marks the task as Failed - it does not undo the action
If the Post-Action Validation fails, the task is marked as Failed but the action is not reversed.
For example, if a Controller version was updated but the instance did not come back online in time, the update already happened. The task outcome reflects that the expected state was not confirmed, not that the action was rolled back. Check the instance state manually if a validation failure occurs.
Configuration Steps#
In the Create Scheduled Action wizard:
- Locate the Post-Action Validation section, after the Acceptance Gates section.
- Optionally, add one or more validations using the Add Validation option.
- Fill in the required fields for each validation.
- Reorder the validations since the evaluation is done based on this order.
- Save and complete the wizard.
If no validations are added, the task is marked as Processed as soon as the action completes successfully.


