Configuring Signals and Skills

Configure Signals to automatically detect process inefficiencies and route them to the right stakeholders. This topic covers defining data models, setting filtering logic to identify incidents, and establishing unique Signal IDs to prevent duplicate tasks.

Before you begin

To configure Signals, you must have Manage Skill permissions. Business users only require My Inbox permissions to view them.

Step 1: Data Model and Result Table

The Result Table is the foundation of your Signal. It determines what data is extracted and how that information is presented to the business user in My Inbox.

Choose your skill type: Decide whether your use case requires a single data source or a cross-process view:
- One-step Skills (Standard): Executes a single PQL query against one Data Model.
  - Best for: Simple alerts where all necessary information exists in one place (e.g., "Overdue Invoices" or "Missing Delivery Dates").
- Multiple-step Skills (Cross-Process): Acts as a data pipeline, linking multiple Data Models sequentially.
  - The "Inner Join" Effect: A Signal is only created if a match exists in the subsequent step. If an ID from Step A isn't found in Step B, no task is triggered.
    Best for: Linking disparate processes, such as identifying how a delay in Procurement (Model A) is impacting a specific Sales Order (Model B).
Configure the result table view: This is where you define the "Columns" the end-user will see.
- Context is King: Include columns that help a user take action without leaving the inbox (e.g., Vendor Name, Total Value, and Days Overdue).
- PQL Power: Use Ctrl + Space in the column editor to create custom PQL expressions (e.g., calculating the margin or formatting a date).
- Hide Technical Noise: Use the Visibility Toggle (eye icon) to include technical IDs required for routing or logic while keeping them hidden from the user's view to prevent clutter.
Sorting and limits:
- Prioritization: Define sorting logic (e.g., Due Date ASC) so the most urgent tasks appear at the top of the user's list.
- Volume Control: By default, results are limited to 50 items per execution to maintain performance. Adjust this in the Sorting tab if your process requires higher volume.

Step 2: Defining Logic (Filtering)

Efficiency in the Action Engine depends on where you apply your filters. To ensure your Skills run quickly and only trigger meaningful incidents, you must distinguish between filtering the dataset and defining the business incident.

Filter type	Purpose	Use case	Impact
Data Model Filter	Restricts the overall scope of data before the Skill processes anything.	Limiting data to specific Company Codes, Regions, or Document Types.	High Performance: Prevents the system from scanning millions of irrelevant rows.
Result Table Filter	Defines the actual "Incident" logic based on your table columns.	Triggering a signal only when `Days Overdue > 10` or `Invoice Status = 'Blocked'`.	Task Accuracy: Decides exactly which rows become actionable tasks in a user's Inbox.

And for the best practice for filtering:

Filter Early: Always apply broad restrictions (like Date ranges or Business Units) at the Data Model level first to keep Skill execution lean.
Handle Nulls: PQL filters often exclude rows with NULL values. If you want to include "Empty" fields in your logic, ensure you explicitly account for them in your filter statement.
Dynamic Thresholds: Use PQL formulas in your Result Table filters to create dynamic logic, such as triggering signals only when a value exceeds a historical average.
The "Invisible" Logic: You can filter on columns that are hidden from the end-user via the visibility toggle, allowing for complex technical routing without cluttering the Inbox.

Step 3: Signal Identity (Critical)

Warning

The Signal ID determines uniqueness. If you change these attributes later, Celonis will re-create all existing signals as new entries, leading to duplicates.

The Signal ID is the unique fingerprint of an incident. It tells the Action Engine whether a detected record is a brand-new issue or an update to one that already exists in a user's Inbox.

This matters because:

Deduplication: Without a properly defined ID, every time the Skill runs, it will create a "new" Signal for the same problem, burying your users in duplicate tasks.
Persistence: If you change these attributes later, Celonis loses the link to the original Signals. The system will treat all existing open tasks as "resolved" and generate a fresh batch of duplicates.

And when looking at what signal to use, a good Signal ID should be immutable (it doesn't change over time) and unique at the line-item level.

Single-Key Identification: If your process has a unique primary key (e.g., Invoice_GUID), use that.
Composite Identification: Most SAP or ERP processes require a combination of columns to ensure uniqueness.
- Example: Sales_Order_Number + Sales_Order_Item + Schedule_Line_Number.
Avoiding "Volatile" IDs: Never use attributes that might change during the process (like "Status" or "Current User") as part of the ID, or you will trigger a new Signal every time that value updates.

Tip

If your result table is intended to be clean and readable, you might feel tempted to exclude technical keys. Instead, include them but hide them. Keep the technical keys in your Result Table configuration so they can serve as the Signal ID, then use the visibility toggle (the eye icon) to hide them from the end-user’s view.

Step 4: Routing and Actions (Optional)

Once the Signal logic is defined, you must determine how the incident is delivered to a user and what tools they have to resolve it. This step bridges the gap between data discovery and business value.

1. Define Routing Rules

Routing ensures the right person handles the right incident. Without rules, Signals may sit unassigned in a general pool.

Simple Routing: Assigns all Signals from a Skill to a specific user or a pre-defined group.
Routing by Data Attribute: Uses columns from your Data Model to drive assignments dynamically (e.g., if the Region is "North America," route to the NA Accounting Team).
Default Assignment: Always define a "Fallback" user or group to ensure unmatched Signals are still addressed.

2. Configure Actionable Steps

The Action is the interface provided to the user in their Inbox to resolve the issue. Provide the most direct path to resolution:

Automated Workflows: Link to an Action Flow to automate repetitive tasks, such as sending emails or updating source systems.
System Deep-Links: Use SAP WebGUI or direct URLs to take the user to the specific transaction record in the ERP.
Knowledge Context: Link to a Celonis Analysis or an SOP document to provide additional context for decision-making.

3. Status and Communication

Status Mapping: Define available statuses for the Signal, such as "In Progress," "Snoozed," or "Resolved."
Notifications: Determine if users receive email digests or real-time alerts for high-priority assignments.