--- alias: user-guide-automation-scheduled-action-acceptance-gates description: "Explain how Acceptance Gates add final checks before an Automation Scheduled Action runs its configured action." --- # Acceptance Gates **Acceptance Gates** are the final validation checks that run after the **Detector** confirms an entity is ready, but before the **Action** executes. Even when an entity is operationally ready, there may be additional conditions that must be met before it is safe or appropriate to act. For example, it may be necessary that the entity has been in a ready state for a minimum amount of time, or that a custom business rule approves the action. While **Detectors** ensure an entity is operationally ready (for example, "The resource is idle"), **Acceptance Gates** ensure it is strategically appropriate to act (for example, "The resource has been idle for at least 10 minutes"). If any **Acceptance Gate** fails, the task is skipped for that evaluation cycle and re-evaluated on the next polling cycle. ![Diagram showing the working of the Acceptance Gates within the Scheduled Action flow.](../diagrams/acceptance_gates.drawio.svg) ## How It Works 1. The **Detector** evaluates the entity instance and confirms it is ready. 2. **Acceptance Gates** are evaluated in the order they are configured. 3. Each **Acceptance Gate** runs as a pass/fail check against the current task state. - All of the **Acceptance Gates** must pass for the task to proceed. - If any **Acceptance Gate** fails, the evaluation stops at that gate and the task is skipped for that cycle. The task remains active and is re-evaluated on the next polling cycle. - If all **Acceptance Gates** pass, the configured task executes. **Acceptance Gates** are re-evaluated from the beginning on every polling cycle. No **Acceptance Gate** state is carried between cycles. ## Acceptance Gate Options The **Acceptance Gates** section allows you to configure one or more validation checks that must all pass before the action runs. Gates run in the order you define them. You can configure multiple gates, and the same gate type can appear more than once. === "Ready Delay" Allows the action to proceed only if the task has been in a ready state for at least a configured amount of time (in seconds). This is useful when a brief ready state is not meaningful. For example, when a resource briefly becomes idle between jobs. Requiring a minimum ready duration avoids triggering actions too early. Ideal for: - Avoiding false triggers when readiness is not meaningful. - Requiring a stabilization period before acting on an entity. - Situations where the operational cost of an action is high and confidence in readiness must be high. Remarks: - The minimum delay must be a non-negative integer. Set it to `0` to allow immediate action once the entity is ready. - The timer is based on `ReadyStateChangedAt`, which records the last time the entity's ready state changed. It is not reset on every polling cycle. - If `ReadyStateChangedAt` is missing, the gate returns `false`. - If `ReadyStateChangedAt` is in the future (for example, due to clock skew), the gate returns `false`. Result: - Returns `True` if the entity has been in a ready state for at least the configured duration. - Otherwise returns `False` and re-evaluates in the next polling cycle. ![Screenshot showing the settings for configuring Automation Scheduled Action acceptance gates with DEE action.](../images/ASC_acceptance_gates_delay.png) === "DEE Action" Determines whether the action is allowed by executing a **DEE action**. The **DEE action** returns the approval decision. Ideal for: - Approval logic is complex or depends on business rules not captured in the standard gates. - The condition depends on external systems or data not available in the task itself. - Standard gates are not sufficient for the use case. You must specify the **DEE action** to use as an **Acceptance Gate**. 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: Acceptance Gate DEE Contract Remarks: - The **DEE action** must complete quickly. Long-running actions can stall the polling loop. - The **DEE action** must not produce side effects. Result: - Returns `True` if the DEE action passes. - Returns `False` if the DEE action fails or throws an error, and re-evaluates in the next polling cycle. ![Screenshot showing the settings for configuring Automation Scheduled Action acceptance gates with DEE action.](../images/ASC_acceptance_gates_dee.png) !!! warning "Acceptance Gates do not replace a well-configured Detector" Acceptance Gates add conditions on top of task readiness. If the Detector is too permissive, entities that are not truly ready will pass through to the gates unnecessarily. Always configure the Detector to accurately reflect operational readiness before adding gates. ## Configuration Steps In the **Create Scheduled Action** wizard: 1. Locate the **Acceptance Gates** section, after the **Detector** section. 2. Select :material-plus: to create a new **Acceptance Gate**. 3. Select the gate type for each entry. 4. Configure any required parameters for each gate. 5. Reorder the gates if the evaluation order matters. 6. Save and proceed to the next section. **Acceptance Gates** are evaluated in the order they appear. If a gate fails, the remaining gates are not evaluated for that cycle. ![Screenshot showing the overall Acceptance Gates configuration in the Create Scheduled Action wizard](../images/ASC_acceptance_gates_total.png)