Skip to content

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.

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.

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.

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.

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