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.

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.

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.

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.

Table 1: Notification Template Triggers

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

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.

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.

Further Resources#