---
alias: tutorials-automation-scheduled-action
title: Configure and use Connect IoT Automation Scheduled Actions
tutorial: deepdive
module: Connect IoT (Equipment Integration)
description: "Learn how to configure and use Connect IoT Automation Scheduled Actions to perform zero-downtime maintenance operations on production lines."
---

# Automation Scheduled Action Tutorial

This tutorial walks through five maintenance scenarios using the Connect IoT **Automation Scheduled Action** feature. All scenarios use a cookie factory as a practical example, but the patterns apply to any Connect IoT deployment.

## 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. It allows you to schedule updates, migrations, and custom operations that wait for safe conditions to avoid production interruptions.

Read [What is Automation Scheduled Action?](what-is-asa.md) for the full definition structure, processing model, and task state reference before working through a scenario.

## Cookie Factory

All scenarios in this tutorial use the same cookie factory. The factory has two production areas - Cookie Manufacturing and Cookie Packing. Manufacturing runs through four sequential steps (Mixing, Molding, Baking, and Cooling) before moving to Packing. Each step contains the physical resources controlled by Connect IoT.

!!! NOTE
    The sample master data in this tutorial prefixes object names with `ASA` (for example, `ASA Mixer-01` and `ASA Packer-01`). Scenario setup and simulation steps use those exact MES names whenever you need to look them up.

```mermaid
graph LR
    subgraph mfg["Cookie Manufacturing"]
        subgraph step_mix["Mixing - Scenarios 1, 3"]
            subgraph mgr_mix["mixing-manager-nextgen"]
                MX1[Mixer-01]
                MX2[Mixer-02]
                MX3[Mixer-03]
            end
        end
        subgraph step_mol["Molding - Scenario 2"]
            subgraph mgr_mol["molding-manager"]
                MD1[Molder-01]
                MD2[Molder-02]
            end
        end
        subgraph step_bak["Baking - Scenario 5"]
            subgraph mgr_bak["baking-manager"]
                BK1[Baker-01]
                BK2[Baker-02]
            end
        end
        subgraph step_cool["Cooling"]
            CL1[Cooler-01]
            CL2[Cooler-02]
        end
        step_mix --> step_mol --> step_bak --> step_cool
    end
    subgraph pack_area["Cookie Packing"]
        subgraph step_pack["Packing - Scenario 4"]
            subgraph mgr_pack["packing-manager"]
                PK1[Packer-01]
                PK2[Packer-02]
            end
        end
    end
    step_cool --> step_pack
```

Each **Resource** has an **Automation Controller Instance** hosted on a dedicated **Automation Manager** per **Step**. However, in Scenario 1, the mixing instances start on `mixing-manager-legacy` and are migrated to `mixing-manager-nextgen` as part of the year-end platform refresh.

All five scenarios in this tutorial are episodes from the same year-end platform refresh at the Cookie Company. The refresh spans three months and involves five separate **Automation Scheduled Action** definitions, each targeting a different **Step** in the factory with a different maintenance pattern:

- Dec 28 - Holiday shutdown begins. Two operations run in parallel on separate resources, but both must complete before production resumes:
    - the mixing manager migration (Scenario 1)
    - the molding controller update (Scenario 2).
- January onwards - Three ongoing operations roll out at their own pace:
    - the mixing controller update triggers on the weekly sanitation cycle (Scenario 3)
    - the packing controller upgrade rolls out as each packer completes its production run naturally (Scenario 4)
    - the baking oven recalibration proceeds whenever the QMS opens a maintenance window (Scenario 5).

## Scenarios

| Scenario | Objective |
|----------|-----------|
| [1. Change Automation Manager](scenarios/01-change-automation-manager-cookie-lines.md) | Move all instances hosted by one manager to another without interrupting production |
| [2. Controller Version Update - Fixed Validity Window](scenarios/02-holiday-shutdown-molding-controller.md) | Update controller version within a bounded window; tasks expire cleanly if the window closes before all instances are processed |
| [3. Controller Version Update - No Materials on Resource](scenarios/03-sanitation-window-ready-delay.md) | Update controller version only after a resource has been continuously empty for a sustained period, with external record confirmation |
| [4. Controller Version Update - Workflow Ready Signal](scenarios/04-update-controller-version-cookie-packaging.md) | Update controller version when the workflow signals each instance is safe - no fixed maintenance window |
| [5. Custom DEE Action at Every Stage](scenarios/05-custom-dee-quality-and-allergen-flow.md) | Use DEE actions at every pipeline stage when built-in types cannot express the required logic or an external system owns each decision |

Table 1: Automation Scheduled Action Tutorial Scenarios

## Before Creating a Definition

Make sure the following are in place before creating a Definition:

- Define an IoT **Integration User** for MES (see [[howto-iot-enable-integration-user]]).
- Define **Resources** as IoT **Integration Entity** (see [[howto-iot-enable-connect-iot-entity]]).
- Load the ASA Cookie Factory masterdata into MES (masterdata package: [01-cookie-factory-base-masterdata.json](./scenarios/masterdata/base/01-cookie-factory-base-masterdata.json)).
- Prepare notification templates if you intend to use them (see [[howto-iot-setup-asa-notification-templates]]).
- Load the scenario automation masterdata for the scenario you are running - each scenario has its own package defined on the pre-requisites section, under `scenarios/masterdata/scenarioXX/` that creates the controllers, managers, and instances for that specific scenario.
- Deploy and verify **DEE actions** if the scenario requires `CustomDeeAction` steps (see [[howto-iot-import-dee-action]]).

!!! warning "Create the Definition in a disabled state"

    Create every Automation Scheduled Action Definition with `IsEnabled` set to `false`.
    Before enabling it, open the generated Tasks and confirm they target only the expected entities.
    Enable the Definition only after verifying the task list is correct.