Skip to content

What Is Automation Scheduled Action?#

Automation Scheduled Action (ASA) is a task-driven maintenance capability that monitors each target runtime and executes the configured maintenance action only when the target is genuinely ready, minimizing production disruption and supporting zero-downtime maintenance patterns.

You define the maintenance rules in an Automation Scheduled Action Definition. When the Definition is created or edited, the system resolves all targets and creates one Automation Scheduled Action Task per target instance. If the Definition is edited after tasks have been created, Context Resolution creates tasks for any newly resolved instances. Tasks already in a terminal state are not affected in either case.

Typical maintenance operations include:

  • Moving instances between Automation Managers.
  • Updating a Automation Controller revision and version.
  • Running custom DEE-driven operations.

Definition#

The Automation Scheduled Action definition is composed of the following parts:

  • Context Resolution - Defines the target entity and resolves it to create tasks for each entity instance.
  • Detectors - Defines how the system determines whether a target instance is currently in a safe state to act on.
  • Actions - Defines the maintenance action to execute when all checks pass.
  • Notifications - Defines the optional notification templates an Automation Scheduled Action task can use during its lifecycle.
  • Pre-Conditions - Defines the time-based or global constraints that must pass before readiness evaluation continues.
  • Acceptance Gates - Defines extra checks that run after the detector reports ready and confirms that it is still safe to proceed.
  • Post-Action Validations - Defines the checks performed after the action runs to confirm it completed successfully.

Processing Model#

When a user creates a new Automation Scheduled Action (ASA) Definition, the system immediately evaluates its scope and generates a unique task for each resolved entity instance.

Every task is evaluated on a recurring polling schedule. To ensure safe and predictable maintenance, the system processes each task through the following phases:

Phase 1: Evaluation (The "Retry" Loop)#

If any check in this phase fails or returns an error, the task is skipped and remains in an Active state. It will be re-evaluated from Step 1 during the next polling cycle.

  1. Eligibility Re-check - Confirms the ASA Definition still exists and is enabled, and that the task has not been manually cancelled.
  2. Expiry Check - Compares the Valid Until timestamp against the current UTC time. If the window has passed, the task moves directly to the Expired state.
  3. Pre-Conditions - Evaluates environmental constraints (e.g., allowed maintenance windows). These use AND semantics; if any condition is not met, evaluation stops and the task is skipped.
  4. Detector - Queries the target entity current state. If the detector reports Not Ready or encounters a runtime error, the task is skipped.
  5. Acceptance Gates - Performs a final safety check (e.g., a required "settling" delay after a detector reports ready). These also use AND semantics.

Phase 2: Execution & Finalization (The "Terminal" Phase)#

Once a task passes all evaluation steps, it enters the execution phase. From this point forward, the task is no longer in the polling loop; it will reach a Terminal state regardless of the outcome.

  1. Action - Executes the maintenance action exactly once. If the action fails (e.g., a timeout or service error), the task is marked as Failed and finalized.

  2. Post-Action Validations - Runs audits after the action completes to confirm the desired outcome (using AND semantics). If a validation fails, the task is marked as Failed.

    Note

    A validation failure indicates the target state is incorrect, but it does not roll back or reverse the action performed in the first step.

  3. Finalize - Updates the final task state and outcome, and triggers any configured notifications (e.g., success/failure logs or emails).

Task Evaluation Flow#

Diagram showing the Task Evaluation of the Automation Scheduled Action.

Fail-closed behavior

Parse errors, runtime errors, and invalid configurations in Pre-Conditions, Detectors, Gates, or Validations are treated as failed checks. The task is not progressed on that pass until the issue is resolved.

Notification delivery

Notification sending is fail-open. Its delivery errors do not block task processing or change the task outcome.

Task States and Outcomes#

Active Outcomes#

A task in active state is still being evaluated on every polling pass. The following outcomes indicate why a given pass was skipped, meaning that the task will be retried on the next evaluation poll.

LastOutcome Reason
SkippedPreConditionFailed A Pre-Condition was not met (for example, outside the allowed weekday or time window).
SkippedNotReady The Detector determined the target is not ready to be acted on yet.
SkippedGateFailed The detector passed but an Acceptance Gate blocked execution (for example, the ready delay has not elapsed).

Table 1: Active Task Outcomes

Terminal States#

Once a task reaches a terminal state it stops being evaluated and will not be retried.

State LastOutcome Meaning
Processed ProcessedSuccess Action was executed and all Post-Action Validations passed.
Ignored IgnoredNoOp Target instance was already in the desired state when the Action ran, so no change was made.
Failed ActionFailed Action execution failed.
Failed ValidationFailed Action ran but a Post-Action Validation failed.
Expired (none) Validity window elapsed before the Action could execute.

Table 2: Terminal Task States

Outcome Quick Reference#

Use this table when diagnosing a task that is not progressing or has reached a terminal state.

LastOutcome State What to check Operator action
SkippedPreConditionFailed Active UTC weekday and time window settings vs. current server time Verify AllowedWeekdays and AllowedTimeWindow against current UTC time.
SkippedNotReady Active Detector inputs: entity state, resource material status, or workflow signal Check the data source for the specific detector type in use.
SkippedGateFailed Active ReadyDelay duration, or custom DEE gate output Check how long the target instance has been in a ready state; verify DEE gate output.
IgnoredNoOp Ignored Target Manager or Controller version in the runtime inventory Confirm if the target is already in the desired state. No action required.
ActionFailed Failed LastError field; Manager/Controller logs; infrastructure capacity Fix the root cause, then re-run per your local process.
ValidationFailed Failed Startup state; I/O connectivity; DEE validation output Diagnose Post-Action state, fix dependencies, then execute a controlled retry.
(no outcome) Expired Validity setting vs. maintenance window duration; task queue depth Increase Validity on a new Definition, or reduce the maintenance queue.

Table 3: Outcome Troubleshooting Reference