---
alias: tutorials-automation-scheduled-action-what-is-asa
description: "Explain the structure, processing model, task states, and outcomes of Connect IoT Automation Scheduled Actions."
---

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

- [[user-guide-automation-scheduled-action-context-resolution]] - Defines the target entity and resolves it to create tasks for each entity instance.
- [[user-guide-automation-scheduled-action-detectors]] - Defines how the system determines whether a target instance is currently in a safe state to act on.
- [[user-guide-automation-scheduled-action-action]] - Defines the maintenance action to execute when all checks pass.
- [[user-guide-automation-scheduled-action#notifications|Notifications]] - Defines the optional notification templates an **Automation Scheduled Action** task can use during its lifecycle.
- [[user-guide-automation-scheduled-action-preconditions]] - Defines the time-based or global constraints that must pass before readiness evaluation continues.
- [[user-guide-automation-scheduled-action-acceptance-gates]] - Defines extra checks that run after the detector reports ready and confirms that it is still safe to proceed.
- [[user-guide-automation-scheduled-action-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.](../../../../userguide/automation/administration/automation-scheduled-action/diagrams/cycle_evaluation.drawio.svg)

!!! note "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.

!!! note "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