Maestro user guide

Last updated Aug 12, 2025

Events

Events provide the ability to capture when something happens during process execution. There are three main types of events in process diagramming: start, intermediate, and end events. These events are also referred to as either "catching" events, which react to a trigger, or "throwing" events.

The UiPath platform supports the following event types and implementations:

Start events behave as catching events. They are triggered by:
- None (starts the process when manually triggered or started via Orchestrator)
- Message events (waiting for an event trigger from Integration Service)
- Timer events (start the process on a schedule or delay, as defined in the trigger configuration)
  A Timer start event begins a process based on a defined schedule rather than user or system input. You can configure it using a Timer section that supports three types: Date, Duration, or Cycle. For recurring executions, use the Cycle type and specify the Repeat frequency (e.g., hourly, daily) and interval. The At and Repetitions fields allow additional control over timing and limits. In the Implementation section, the Action can be set to None if no inbound event is needed, or Wait for connector event if the process should also listen for an external trigger before proceeding. Timer start events are ideal for scheduled automations such as hourly syncs or daily reports. Read more about Integration Services connectors.
Intermediate catching events behave similarly to start events. They wait for a message, timer, or API trigger during process execution. Execution is paused until the message is received.
Boundary events are a special type of intermediate catching event attached to a task. They can be configured as:
- Interrupting boundary events: When the attached task starts, the boundary event waits for its trigger. If triggered while the task is still executing, it interrupts the task and continues along the boundary event's outgoing path. Interrupting boundary events can be triggered by Timer, or Message events.
  A timer boundary event allows you to interrupt a task if it takes too long to complete. You can configure the timeout using either a Duration, a specific Date, or a Cycle (for recurring timers). In the properties panel, the Type field determines the timer mode, and the Value field accepts ISO 8601 time expressions (e.g., PT1H for one hour). If the timer expires while the task is still running, the process continues along the boundary event’s outgoing path. The Implementation section lets you optionally define actions to take when the timeout is triggered, though it's commonly left as None if the follow-up logic is modeled downstream.
  
  A message boundary event listens for a specific message while the activity it’s attached to is still running. If the message arrives, it interrupts the ongoing task and diverts the flow to a separate path. You can define the message handling logic in the Implementation section by selecting an available action (e.g., wait for connector event or external input). Use the Inputs and Outputs sections to pass or extract data from the incoming message. You can also use Update variables to modify process data in response to the message. If no message is received, the original task continues uninterrupted.
- Non-interrupting boundary events: When triggered, they create a new execution token and continue along a parallel path without interrupting the original task execution. Non-interrupting boundary events can be triggered by Timer and Message events.
- Error boundary events: An Error boundary event is used to catch and handle errors that occur in the activity it is attached to. If an error is thrown, control exits the activity and flows down the boundary event path. By default, the Exception is set to Catch all, which means it captures any unhandled error. In most cases, this path acts as a fallback or "ultimate" error-handling route. The Implementation section allows you to optionally define actions (such as logging or notifying), but it can be left as None if no specific execution is required within the boundary event.
Intermediate throwing events actively send a trigger. For example:
- A message intermediate throwing event acts like a Send task, invoking an Integration Service API execution.
End events mark the completion of a process and behave as throwing events. They can be:
- Error end events, which complete the process instance and fault the Orchestration Runtime (OR) job.
- Message end events, which send a message as the process concludes. A Message end event can be configured to execute a connector activity when the process reaches its end. By selecting "Execute connector activity" as the implementation action, you can trigger an outbound operation using any connector available in Integration Service—such as Slack, Salesforce, ServiceNow, or others. This is commonly used to notify external systems, update records, send messages, or upload files upon successful or failed process completion. You must select the target Connector, define the Connection, and choose the specific Activity to run. Inputs allow you to pass data to the connector, while Outputs let you capture and store the connector’s response or result for use elsewhere in the process. Read more about Integration Services connectors.
- Terminate end event, which cancels all other execution paths/tokens, especially when multiple branches run in parallel. An End event signifies the conclusion of a process path. In Maestro, you can optionally define an Implementation Action to perform a final activity—such as executing a connector operation, returning data, or triggering a follow-up system. If no action is needed, the implementation can be set to None, which simply ends the process flow. The Arguments section allows you to define output values that can be passed to parent processes or used in downstream reporting. End events are flexible and can be used to close both standard and exceptional paths, depending on how the process is modeled.