---
alias: user-guide-automation-scheduled-action
description: "Explain Automation Scheduled Actions, including how definitions and tasks work, available notifications, and related documentation."
---

# Automation Scheduled Action

An **Automation Scheduled Action (ASA)** automates maintenance operations on Connect IoT Automation Instances and supports zero-downtime operation. The **Scheduled Action** monitors the configured instances and triggers the selected operation automatically when conditions are met.

Access this functionality on the **Automation** tab, in the **Administration** section.

![Screenshot showing where to find the Automation Scheduled Action](images/ASC_entity_location.png)

The **Scheduled Action** functionality only triggers a maintenance activity when an **Automation Instance** is in a ready state, meaning it is safe to act on it without disrupting production. This is what zero-downtime operation means in practice.

![Diagram showing the Processing Flow of the Automation Scheduled Action.](diagrams/processing_flow.drawio.svg)

## How It Works

An **ASA** is built around two objects:

- **Definition** - the configuration you create once. It describes which instances are in scope, what condition signals they are ready, what action to perform, and how to validate the result.
- **Task** - one record per target instance, created automatically when the Definition is saved. Each task is evaluated independently on every polling cycle until it either completes, expires, or fails.

When you create a Definition, the system resolves the target instances with the **Context Resolution** you configured and creates one Task per instance. From that point, each Task goes through the following stages on every polling cycle:

1. **Pre-Conditions** - checks that must pass before evaluation proceeds (for example, is today an allowed weekday, or is the current time within an allowed window?).
2. **Detector** - the configured detector checks whether the instance is currently in a safe state to act on, also known as Ready State detection.
3. **Acceptance Gates** - additional checks that run only when the task is ready (for example, has it been ready long enough, or does a custom rule approve the action?).
4. **Action Execution** - the configured maintenance action is performed on the instance.
5. **Post-action validation** - after the action runs, the system verifies if the instance reached the expected outcome (for example, if it restarted successfully within the allowed time).

If any stage fails, the task is skipped for that cycle and re-evaluated on the next one. A task only reaches a terminal state when an action is actually attempted or when the validity window closes.

![Diagram showing the Per-Cycle Evaluation of the Automation Scheduled Action.](diagrams/cycle_evaluation.drawio.svg)

Each task ends in one of four terminal states:

- `Processed` - the action ran and post-action validations passed successfully.
- `Ignored` - the action was a no-op (the instance was already in the target state). No change was made.
- `Failed` - the action failed, or the post-action validations did not pass.
- `Expired` - the validity window closed before the task could complete.

Non-terminal outcomes such as `not ready` or `gate failed` are recorded in the task's **Last Outcome** field for visibility. You can verify the result of each task in the **Automation Controller** page, in the **Instances** section.

## Notifications

Notifications are configured by entering the name of an existing MES Notification Template in the corresponding field on the Definition. If a field is left empty, no notification is sent for that event.

| Notification Template | When it is sent                                    |
|-----------------------|----------------------------------------------------|
| **Pre Action**        | Immediately before the action executes             |
| **Success**           | When the task completes with a `Processed` outcome |
| **Failure**           | When the task reaches a `Failed` outcome           |
| **Ignored**           | When the task ends as `Ignored` (no-op)            |

Table 1: Notification Template Triggers

!!! Note "Notifications are best-effort"
    A failure to send a notification does not block or affect task processing.

To produce meaningful alerts, notification templates support tokens that are replaced with task-specific values at send time. The following tokens are available:

| Token                          | Description                                                                                 |
|--------------------------------|---------------------------------------------------------------------------------------------|
| `{{AutomationInstanceId}}`     | The unique identifier of the Automation Instance the action was performed on.               |
| `{{AutomationInstanceName}}`   | The name of the Automation Instance the action was performed on.                            |
| `{{DefinitionId}}`             | The unique identifier of the definition associated with the task.                           |
| `{{DefinitionName}}`           | The name of the definition associated with the task.                                        |
| `{{EntityId}}`                 | The unique identifier of the MES entity associated with the task.                           |
| `{{EntityName}}`               | The name of the MES entity associated with the task.                                        |
| `{{EntityTypeId}}`             | The unique identifier of the entity type.                                                   |
| `{{LastError}}`                | The last error recorded on the task, if any.                                                |
| `{{LastOutcome}}`              | The outcome of the last evaluation (for example, `ProcessedSuccess` or `ValidationFailed`). |
| `{{TaskId}}`                   | The unique identifier of the task.                                                          |
| `{{TaskName}}`                 | The name of the task.                                                                       |

Table 2: Notification Template Tokens

Example template configuration: the following shows a template configured for a success notification.

- The `Title` provides a summary visible in the notification list.
- The `Details` field contains a richer breakdown for operators who open it.

```json
Title:
Automation task {{TaskName}} (ID {{TaskId}}) finished with {{LastOutcome}}

Details:
Task={{TaskName}} ({{TaskId}}); Definition={{DefinitionName}} ({{DefinitionId}});
Entity={{EntityName}}; Automation={{AutomationInstanceName}}; LastError={{LastError}}
```

Configuring at least a **Failure** notification is strongly recommended so that operators are informed when an action does not complete as expected. A **Pre Action** notification is useful for high-impact operations such as version updates, where teams need advance notice before the operation runs.

## Scheduled Action Entity Page

Once a Definition is created, you can open it to see its full configuration and the list of tasks generated from it. The page is divided into sections accessible via tabs on the right panel: **Details**, **Scheduled Tasks**, **Context**, **Detector**, **Action**, **Pre Conditions**, **Acceptance Gates**, **Post Action Validations**, and **Attachments**.

The **Scheduled Tasks** section shows all tasks generated from this Definition, with columns for entity, automation instance, creation date, state, validity, readiness, last evaluation time, last outcome, and last error. You can filter tasks by state or universal state.

!!! Note "Importing a Scheduled Action Definition"
    You can import a pre-configured Scheduled Action Definition by loading a master data package. When a package is loaded, the Definition is created (or updated) as if it had been configured manually, and Context Resolution runs to generate the corresponding tasks.

![Screenshot showing the Automation Scheduled Action entity page](images/ASC_entity_page.png)

## Further Resources

<div class="grid cards" markdown>

- **Operations**

    ---
    Learn more about Scheduled Action operations here:

    [Create Scheduled Action](./operations/automation_scheduled_action_create.md)

    [Edit Scheduled Action](./operations/automation_scheduled_action_create.md)

    [Enable/Disable Scheduled Action](./operations/automation_scheduled_action_enable_disable.md)

- **Elements**

    ---

    Learn more about the elements that form a Scheduled Action here:

    [Context Resolution](./elements/automation_scheduled_action_context_resolution.md)

    [Detector](./elements/automation_scheduled_action_detectors.md)

    [Action](./elements/automation_scheduled_action_actions.md)

    [Pre-Conditions](./elements/automation_scheduled_action_preconditions.md)

    [Acceptance Gates](./elements/automation_scheduled_action_acceptance_gates.md)

    [Post Action Validations](./elements/automation_scheduled_action_post_actions_validations.md)

- **Workflow Tasks**

    ---
    If you use the "Defined in Workflow" Detector, learn more about the related tasks here:

    [Ready State Request Task](../../reference/tasks/core/zero-downtime/task_ready_state_request.md)

    [Send Ready State Reply Task](../../reference/tasks/core/zero-downtime/task_send_ready_state_reply.md)

- **Tutorials**

    ---
    Find Scheduled Action tutorials here:

    [[tutorials-automation-scheduled-action]]

</div>