---
alias: user-guide-automation-scheduled-action-post-action-validations
description: "Explain how Post-Action Validations confirm the result of an Automation Scheduled Action after the configured action runs."
---

# 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.

![Diagram showing the working of the Post-Action Validation within the Scheduled Action flow.](../diagrams/post_action_validation.drawio.svg)

## How It Works

Once the **ASA** task action is done, the task enters the validation phase:

1. Each configured **Post-Action Validation** runs, in order, against that task.
2. 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 as `Processed`.
    - `False` - if any of the validations failed, or an error occurred during validation, the task is marked as `Failed`.

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:

=== "Max Startup Time"

    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 `True` if the instance reaches a `Running` state within the configured time.
    - Returns `False` if the instance does not start in time, and the task is marked as `Failed`.

    ![Screenshot showing the settings for configuring the Max Startup Time post-action validation.](../images/ASC_post_action_validations_time.png)

=== "DEE Action"

    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 `True` if the DEE action is successful The task is marked as `Processed`.
    - Returns `False` if the DEE action fails or throws an error. The task is marked as `Failed`.

    ![Screenshot showing the settings for configuring the DEE Action post-action validation.](../images/ASC_post_action_validations_dee.png)

!!! warning "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:

1. Locate the **Post-Action Validation** section, after the **Acceptance Gates** section.
2. Optionally, add one or more validations using the **Add Validation** option.
3. Fill in the required fields for each validation.
4. Reorder the validations since the evaluation is done based on this order.
5. Save and complete the wizard.

If no validations are added, the task is marked as `Processed` as soon as the action completes successfully.

![Screenshot showing the settings for configuring post-action validations.](../images/ASC_post_action_validations_general.png)