Actions#

The Action is the operation that the Automation Scheduled Action (ASA) performs on an entity once it is confirmed ready.

Each Scheduled Action has exactly one configured Action. The Action only runs after all configured prerequisite steps ( Pre-Conditions, Detector, and Acceptance Gates) have cleared successfully.

How It Works#

All previous steps pass: Pre-Conditions, Detector, and Acceptance Gates.
The configured Action for the ASA task runs.
One of the following outcomes occurs:
- Ignored - the action would result in no change (for example, the entity is already on the target version). No changes are made.
- Failed - the action could not complete. The task is marked as failed.
- Succeeded - the action completed. The flow moves on to Post-Action Validation.

Actions are the only step in the flow that change system state. All other steps are read-only checks.

Action Options#

The Action section allows you to select one of 3 possible actions:

Update Controller VersionChange Automation ManagerDEE Action

Stops the current Automation Controller Instance and updates it with a new one using the specified revision and version of the same controller.

Specify the Automation Controller you want to update, as well as the target revision and version.

If the running instance is already on the specified revision and version, the action does not run and the task is marked as Ignored.

Ideal for:

Rolling out a new controller version to instances without manual intervention.
Scheduling version updates to happen only when the entity is idle.

Result:

The instance is stopped, and updated with a new one with the specified revision and version.
If the target is already running, the task is marked Ignored with no changes made.

Stops the current Automation Controller Instance and updates it with a new one hosted by the specified Automation Manager.

You must specify the target Automation Manager for the change.

If the instance is already hosted by the specified manager, the action does not run and the task is marked as Ignored.

Ideal for:

Moving instances between managers as part of infrastructure changes.
Rebalancing workloads across managers during a maintenance window.

Result:

The instance is stopped, and updated with a new one under the specified manager.
If the target manager is already hosting the instance, the task is marked Ignored with no changes made.

Runs a DEE action as the scheduled action. The DEE action defines the full behavior.

Ideal for:

Custom maintenance operations not covered by the built-in action types.
Actions that depend on external systems or complex business logic.

You must specify the DEE action to use. Make sure its inputs and outputs match the DEE contract:

Direction	Key Name	Data Type	Description
Input	`Task`	`AutomationScheduledActionTask`	Context about the task being executed.
Output	`Result`	`Boolean`	`true` = Pass, `false` = Fail.

Table 1: Action DEE Contract

Result:

Runs the configured DEE action and uses the boolean output to determine success or failure.

Actions stop and restart the instance

Both Update Controller Version and Change Automation Manager stop the running instance and start new processes for it. See What the Action Costs at Run Time. Make sure the Detector and Acceptance Gates are set up to confirm the entity is idle before the action runs. Acting on an instance that is still processing work will interrupt it.

What the Action Costs at Run Time#

The two built-in actions treat the instance differently:

	Update Controller Version	Change Automation Manager
Instance	Kept, with its name and ID. Its controller version changes, and its driver instances are created again, one for each driver, matched to the drivers of the target version by name.	Stopped and terminated. A new instance, with a new name and ID, is created for the same entity and controller version on the target Automation Manager.
Processes	The instance restarts on the same Automation Manager.	The target Automation Manager starts the processes of the new instance.
Fails when	The target version has a different number of drivers, or a driver cannot be matched by name.	The action cannot stop or terminate the instance, or cannot create the new one.
Data store	Kept: the store belongs to the instance ID, in the persistency location of the same Automation Manager.	The new instance has a new ID and an empty store in the persistency location of the target Automation Manager. It does not read the values of the old instance, even when both managers share the persistency folder.

Table: What each action does to the instance

In both cases, the new processes know only what MES holds:

Every workflow of the controller starts again, and each Setup chain runs again from OnInitialize.
Values stored as Temporary are lost.
A file driver with ignoreInitial set to false reports every file still in its folder as new.
The entity has no automation from the stop until its drivers are Communicating again. MES requests to the instance in that period get no reply from the workflow, so choose a Detector that holds the action while MES can send them. A request still pending when the instance stops gets no reply either: MES receives null when the timeout of the request expires. The gap lasts from about 1 to 20 seconds.

For the restart itself and the log lines that confirm it, see Connect IoT Runbook. To design an integration that a scheduled action can restart at no cost, see What Is Automation Scheduled Action?.

Configuration Steps#

In the Create Scheduled Action wizard:

Locate the Action section, after the Detector section.
Select one of the available action types.
Fill in the required fields for the selected action.
Proceed to the next section.

Only one action can be configured per Scheduled Action.