---
alias: user-guide-automation-scheduled-action-detectors
description: "Explain the detector types available for Automation Scheduled Actions and how they determine whether a target entity is ready."
---

# Detectors

**Detectors** determine whether an entity is operationally ready for an **Automation Scheduled Action (ASA)** task to proceed.

After the **Context Resolution** defines which entities enter the flow, and the **Pre-Conditions** filter task eligibility, the **Detector** evaluates the runtime state of each entity. It decides if the **Scheduled Action** can continue for that entity, preventing actions from executing while the entity is active, processing **Materials**, or otherwise not ready.

A **Detector** is a readiness rule evaluated per entity at runtime. It only determines readiness, so it does not execute actions.

![Diagram showing the working of the Detector within the Scheduled Action flow.](../diagrams/detector.drawio.svg)

## How It Works

1. The **Scheduled Action** task is triggered.
2. **Pre-Conditions** determine task eligibility.
3. The **Detector** evaluates each entity’s runtime state according to the configured rule. The evaluation results in one of the following outcomes:
    - `False` - if the entity is not ready, the **Scheduled Action** task waits and re-evaluates during the next polling cycle.
    - `True`- if the **Detector** condition is satisfied, the entity moves forward in the automation flow.

**Detectors** are evaluated repeatedly according to the polling interval configured for the **Scheduled Action**.

Entities that do not proceed are skipped and are evaluated again according to the polling interval configured for the **Scheduled Action**.

## Detector Options

The **Detector** section lets you specify which readiness rule is applied to the entity selected previously.

=== "Defined in Workflow"

	Determines readiness based on workflow progression.
	The entity becomes ready when it reaches a specific point in its workflow execution.

	For this option, it is essential you configure a workflow in the **Automation Controller** using [[user-guide-automation-task-core-ready-state-request]] and [[user-guide-automation-task-core-send-ready-state-reply]] beforehand.
	
	Ideal for:

	- The system must wait for a process checkpoint.
	- Readiness depends on business process state rather than system state.

	Result:

	- Returns `True` when the workflow condition is met.
	- Otherwise returns `False` and re-evaluates in the next polling cycle.

=== "DEE Action"

	Determines readiness by executing a **DEE action**. The **DEE action** returns the readiness decision.
	
	Ideal for:

	- Readiness logic is complex.
	- Readiness depends on external systems.
	- Standard **Detectors** are not sufficient.

    Specify the **DEE action** you want to use as a **Detector**. Make sure its inputs and outputs match the DEE contract:
	
	| Direction  | Key Name | Data Type                       | Description                                              |
	|------------|----------|---------------------------------|----------------------------------------------------------|
	| **Input**  | `Task`   | `AutomationScheduledActionTask` | Provides context about the current task being validated. |
	| **Output** | `Result` | `Boolean`                       | Determines the outcome. `true` = Pass, `false` = Fail.   |

    Table 1: Detector DEE Contract

    Result:

    - Executes the configured DEE action and outputs a readiness indicator (boolean).
  
    ![Screenshot showing the settings for configuring Automation Scheduled Action detectors with DEE action.](../images/ASC_detectors_dee.png)

=== "Entity State In List"

	Determines readiness by checking whether the entity’s current state is included in a defined list of allowed states.

    You must define the list of valid states first.

    Ideal for:

    - Readiness depends strictly on lifecycle state.
    - Specific states clearly represent idle or safe modes.
    
	Result:

    - Returns `True` if the current state matches one of the allowed states.
    - Otherwise returns `False` and re-evaluates in the next polling cycle.

    This is one of the most common zero-downtime configurations.

	![Screenshot showing the settings for configuring Automation Scheduled Action detectors with entity state in list option.](../images/ASC_detectors_entity.png)

=== "No Materials on Resource"

	Determines readiness by verifying that no **Material** is assigned to the **Resource**. 
    Sub-resources are not evaluated.

	Ideal for:

	- The Scheduled Action must not interrupt production.
	- The action affects runtime execution (for example restart or upgrade).

    Result:

	- Returns `True` when no materials are assigned.
	- Otherwise returns `False` and re-evaluates in the next polling cycle.

	This **Detector** directly enforces zero-downtime principles.  

!!! warning "Avoid weak readiness criteria"
    If a Detector condition is too permissive, actions may execute while the entity is still operational.
    Always align Detector logic with the operational impact of the configured Action.

For actions such as restart, reassignment, or update, ensure the **Detector** prevents execution during active processing.

## Configuration Steps

In the **Create Scheduled Action** wizard:

1. Locate the **Detector** field under the Context section.
2. Select one of the available **Detector** types.
3. Configure any additional required parameters depending on the selected option.
4. Save and proceed to the next section.

Each entity resolved in the **Context Resolution** step will be evaluated using the selected **Detector** configuration.

![Screenshot showing the settings for configuring Automation Scheduled Action detectors.](../images/ASC_detectors_total.png)