> For the complete documentation index, see [llms.txt](https://admin-docs.onestop.site/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://admin-docs.onestop.site/managing-services/building-the-workflow/events.md).
# Events
## Intermediate Events
Intermediate Events allow a workflow to listen for, or dispatch an event at a specific point in its execution — enabling communication between workflows, timed delays, or synchronization with external triggers.
To add an Intermediate Event to a workflow:
1. Drag the **Intermediate Event** element from the toolbar onto the workflow canvas.
2. Enter a **Task Title** to label the step (e.g., "Test").
3. Under **Create or select an event code**, choose the **Event Direction**:
* **Catch (Listens to event)** – The workflow pauses at this step until the specified event is received.
* **Throw (Dispatches event)** – The workflow sends out the specified event to notify other listening steps or workflows.
## Configuring a Catch Event
When **Catch** is selected, additional fields appear:
| Field | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Title** | A descriptive name for this event configuration (e.g., "New Event Config"). |
| **Event Code** | The unique code the step listens for. You can select an existing event code from the dropdown or create a new one. |
The Event Code dropdown displays previously configured codes along with their type, shown in parentheses:
* **Signal** – A custom event code manually triggered elsewhere in the workflow (e.g., *Event A – A (Signal)*, *Event B – B (Signal)*).
* **Timer** – A time-based event that fires automatically after a set duration (e.g., *30 SECONDS WAIT – WAIT-30 (Timer)*).
You can also create a brand-new event code directly from this field using the **+** button beside the Event Code dropdown.
## Configuring a Throw Event
When **Throw** is selected, the step is configured to dispatch a chosen event code, which any corresponding **Catch** step elsewhere in the workflow (or in another workflow) can listen for.
#### Notes
* Event codes can be reused across multiple Catch/Throw steps to synchronize different parts of a workflow, or even across separate workflows.
* Timer-based events (like "30 SECONDS WAIT") are useful for introducing scheduled delays without requiring an external trigger.
* Once the required fields are complete, click **Continue** to save the Intermediate Event configuration.
## Creating a New Event Code
If the event code you need doesn't already exist, you can create one directly from the **Event Code** dropdown using the **+** button. This opens the **Event Code** configuration dialog.
Provide the following configuration details:
| Field | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | A descriptive, human-readable name for the event code (e.g., "Order Approved"). |
| **Code** | The unique identifier used internally to reference this event (e.g., "APPROVED"). |
| **Event Type** | The category of event this code represents. Selecting an event type may reveal additional configuration fields specific to that type. |
**Event Type Options**
The **Event Type** dropdown offers the following options:
| Event Type | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Timer** | Fires automatically after a defined duration or schedule, rather than waiting on a manual trigger. Supports ISO 8601 and Cron-based expressions. |
| **Error** | Fires when a specific error condition occurs within the workflow, allowing the process to catch and handle exceptions. |
| **Signal** | A manually-triggered event, dispatched by a **Throw** step elsewhere in a workflow and picked up by a matching **Catch** step. |
| **Message** | Represents an event triggered by an incoming message, typically used for communication between processes or external systems. |
| **Escalation** | Signals that a situation requires attention beyond the normal flow, often used to notify a parent process or supervisor step. |
| **Compensation** | Triggers a compensating action to undo or roll back the effects of a previously completed step, typically used in error-recovery scenarios. |
Once the required fields (**Name**, **Code**, and **Event Type**) are filled in, click **SAVE** to create the event code. It will then be available for selection in the Event Code dropdown for any Intermediate or Boundary Event across your workflows.
> **Note:** Depending on the **Event Type** selected, additional configuration fields specific to that type (e.g., timer expressions for Timer events) will appear before saving.
## Signal Events
Signal Events are a type of event code used to synchronize activity between steps in a workflow — or between separate workflows entirely. Unlike Timer events, which fire automatically after a set duration, Signal events only fire when explicitly dispatched by a **Throw** step.
**Selecting a Signal Event Code**
Once a Signal event code has been created, it becomes available in the **Event Code** dropdown for any Event step. In the example above:
* **Event Direction** is set to **Catch (Listens to event)**.
* The **Event Code** field
Once an event code is selected, the field provides quick-access controls:
| Icon | Action |
| ------------ | -------------------------------------------------------------------------------------------------------- |
| ✏️ (Edit) | Opens the Event Code configuration dialog to modify the Name, Code, or Event Type of the selected event. |
| ✕ (Clear) | Removes the currently selected event code from the field. |
| ▼ (Dropdown) | Reopens the list of available event codes to choose a different one. |
| **+** (Add) | Opens the Event Code configuration dialog to create a brand-new event code. |
**How Signal Events Work**
1. A **Catch** step configured with a Signal event code (e.g., `A`) will pause the workflow at that point until the matching signal is received.
2. A **Throw** step — placed elsewhere in the same workflow, or in a different workflow — is configured with the same event code to dispatch the signal.
3. When the Throw step executes, any Catch step listening for that same event code resumes execution.
This makes Signal events useful for:
* Coordinating steps across parallel branches of a workflow.
* Synchronizing two or more separate workflows that need to communicate with one another.
* Pausing a process until a specific business condition or external action is signaled.
Once the Event Code is selected, click **CONTINUE** to finalize the Event configuration.
## Timer Events
Timer Events are a type of event code that fire automatically after a defined period of time, without requiring a manual trigger. They're ideal for introducing delays, deadlines, or recurring scheduled actions into a workflow.
When an Event uses an Event Code configured as **Timer** (e.g., `WAIT-30 | 30 SECONDS WAIT (Timer)`), a set of additional fields appears to define exactly when and how the timer fires.
### **Countdown From**
This field determines the reference point the timer counts down from. Available option shown:
* **Task Created** – The countdown begins from the moment the task/step is created.
* **Task Assigned** – The countdown begins from the moment the task/step is assigned.
* **Task Started** – The countdown begins from the moment the task/step is started.
### **Timer Expression Type**
You can define the timer's schedule using one of two expression types:
* **ISO 8601** – Best suited for expressing durations, periods, and time intervals relative to a start point.
* **Cron** – Best suited for expressing recurring points in time (e.g., every day at midnight, every Tuesday at 10am).
#### **ISO 8601 Expressions**
When **ISO 8601** is selected, enter a **Timer Expression** using one of the following formats:
* **A duration expression** — represents a length of time (e.g., `PT1H` for 1 hour).
* **A time interval expression** — represents a span between two points, in one of four forms:
| Format | Example | Meaning |
| -------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `/` | `2007-03-01T13:00:00Z/2008-05-11T15:30:00Z` | A fixed interval between two dates. |
| `/` | `2007-03-01T13:00:00Z/PT1H` | 1 hour after the given start date/time. |
| `/` | `PT1H/2007-03-01T13:00:00Z` | 1 hour before the given end date/time. |
| `` only | `PT1M` | Counts from the task's Created/Assigned/Started date (per the **Countdown From** field) — e.g., 1 month after task creation. |
#### **Advanced: Recurring Intervals**
Toggling **Use advanced ISO 8601 Interval expression?** allows you to define a more complex timer e.g. a **recurring** timer. Recurring timers are defined by prefixing the interval with `R` and an optional repeat count. If no count is given, the recurrence is unbounded (repeats forever).
Examples:
* `R2/PT1H` – Fires 1 hour after task creation, then repeats 2 more times, 1 hour apart (3 total events).
* `R/PT1H` – Fires 1 hour after task creation, then repeats indefinitely, 1 hour apart.
* `R2/2026-01-01T00:00:00/PT1H` – Fires 1 hour after midnight on 2026-01-01, then repeats 2 more times, 1 hour apart (3 total events).
* `R2/PT1H/2026-01-01T00:00:00` – Fires 1 hour before midnight on 2026-01-01, then repeats 2 more times, 1 hour apart (3 total events).
> **Important:** To stop an unlimited (`R/...`) recurring timer that's already running, you must reconfigure the expression — this change will apply to all active process instances affected.
>
> ISO 8601 expressions are best for durations and periods. To schedule a **recurring point in time** (e.g., every day at midnight, every Tuesday at 10am), use a **Cron** expression instead.
#### **Cron Expressions**
When **Cron** is selected as the Timer Expression Type, enter a **Cron Expression** to define a recurring schedule.
Supported formats:
| Format | Example | Meaning |
| -------------------------------------------------------- | ------------------- | ------------------------------------------------------ |
| `minute hour day_of_month month day_of_week` | `0 0 * * *` | Every day at midnight |
| `second minute hour day_of_month month day_of_week` | `30 0 0 * * *` | Every day at midnight and 30 seconds |
| `second minute hour day_of_month month day_of_week year` | `30 0 0 * * * 2027` | Every day at midnight and 30 seconds, in the year 2027 |
**Nonstandard predefined scheduling keywords** (`@` expressions) are also supported:
| Keyword | Meaning |
| ----------- | -------------------- |
| `@midnight` | Everyday at midnight |
| `@hourly` | Every hour |
| `@daily` | Everyday |
| `@weekly` | Every week |
| `@monthly` | Every month |
| `@yearly` | Every year |
Once the timer configuration is complete, click **CONTINUE** to save the Intermediate Event step.
## Boundary Events
Boundary Events attach to a specific activity step e.g. a User Task or Call Activity step and let the workflow listen for an event *while that step is active*. When the event fires, a designated target node is activated — either alongside the original task or, if configured as interrupting, in place of it. Boundary events only truly work when a task step takes time to be executed e.g. a human task, a call activity, a prolonged syncrhonous service task etc.
**Accessing Boundary Events**
Boundary Events are configured from within a task step's settings:
1. Open the task step.
2. Navigate to the **EVENTS** tab of the task.
3. Here you'll find an explanation of how boundary events work
4. Click **+ ADD BOUNDARY EVENT** to create a new one.
**Configuring a Boundary Event**
Clicking **ADD BOUNDARY EVENT** opens the **Boundary Event Configuration** dialog, with the following fields:
| Field | Description |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Title** | A descriptive name for this boundary event (e.g., "New Boundary Event"). |
| **Target Node** | The step that will be activated when the event fires (e.g., "Reminder Notification"). |
| **Event Configuration** | The event configuration this boundary event listens for. Select an existing code or create a new one, just like with Intermediate Events. A boundary event configuration can only be a catch event. |
| **Enabled** | Toggle to activate or deactivate this boundary event without deleting it. |
| **Interrupting Boundary Event?** | If enabled, the original task (e.g., "Approve") is cancelled once the event fires and the target node is activated instead. If disabled (non-interrupting), the target node runs *alongside* the original task, which continues normally. |
Once configured, click **SAVE**.
**Result**
After saving, the boundary event appears as a small icon attached to the task step on the workflow canvas (shown as a dashed line connecting to the target node). The **EVENTS** tab also lists a summary of each configured boundary event, for example:
> **New Boundary Event** — Activates **Reminder Notification** on catching the **WAIT-30 - Timer** event.
From here, you can:
* **EDIT** — Reopen the Boundary Event Configuration dialog to make changes.
* **DELETE** — Remove the boundary event entirely.
You can attach multiple boundary events to a single task by repeating the **+ ADD BOUNDARY EVENT** process.
**Use Cases**
* **Non-interrupting** — Send a reminder notification while the user still has time to complete the original task (e.g., a "30 seconds wait" timer triggering a reminder without cancelling the Approve task).
* **Interrupting** — Automatically escalate or cancel a task if it isn't completed within a certain time, or if a specific signal/error event is received.
***