Events

Events capture what happens during process execution. In BPMN, events are grouped into three main types: Start, Intermediate, and End events. These can behave as either catching events (which react to a trigger) or throwing events (which send a trigger).

Start events

Start events define how a process begins. They are always catching events and can be triggered manually, by a message, or on a schedule.

• None — starts the process when manually triggered or started via Orchestrator.
• Message events — triggered by an event from Integration Service.
  
  
  
  
• Timer events — start the process on a schedule or delay.

  A Timer start event begins a process based on a defined schedule rather than user or system input. Configure it using the Timer section, which supports Date, Duration, or Cycle types.

  For recurring executions, use Cycle and specify the Repeat frequency (for example, hourly or daily). The At and Repetitions fields provide additional control over timing and limits.

  In the Implementation section, set the Action to None if no inbound event is required, or to Wait for connector event if the process should listen for an external trigger before proceeding. Timer start events are ideal for scheduled automations such as hourly syncs or daily reports. Read more in Integration Service connectors.

  
  
  
  
  

Intermediate events

Intermediate events represent something that happens between the start and end of a process. They can delay flow, wait for input, handle errors, or signal other activities.

Intermediate catching events wait for a message, timer, or API trigger during execution. The process pauses until the trigger occurs.

Boundary events are a special type of intermediate catching event attached to a task. They can be configured as follows:

• Interrupting boundary events — cancel the attached task when triggered (for example, by a Timer or Message).
  Timer boundary event: Interrupts a task if it runs too long. Configure a Duration, specific Date, or recurring Cycle. The Value field accepts ISO 8601 durations (e.g., PT1H for one hour). When the timer expires, the process continues along the boundary event path.

  The Implementation section can include actions such as logging or retries, though it’s commonly left as None.

  
  
  
  
  

  Message boundary event: Listens for a specific message while the task runs. When received, it interrupts the task and diverts flow along a new path.

  Define message handling logic in the Implementation section (for example, Wait for connector event or External input). Use the Inputs and Outputs sections to pass or extract data, or Update variables to modify process data dynamically.

  
  
  
  
  
• Non-interrupting boundary events — trigger a parallel path while allowing the task to continue running. Can be Timer or Message based.
• Error boundary events — handle errors thrown by the attached activity. By default, the Exception is set to Catch all, meaning it captures any unhandled error. This path usually acts as a fallback or recovery route.
  
  
  
  

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

End events mark the completion of a process path and behave as throwing events. They may end the workflow normally, send data outward, or terminate all active paths.

• Error end event — completes the process instance and faults the Orchestration Runtime (OR) job.
• Message end event — sends a message when the process concludes. You can configure it to execute a connector activity (for example, Slack, Salesforce, or ServiceNow) using the Execute connector activity implementation.

  Select the target Connector, define the Connection, and choose the Activity to run. Inputs pass data to the connector, while Outputs capture and store responses for use in later steps.

  
  
  
  
  
• Terminate end event — cancels all other execution paths, especially in parallel flows. It marks the complete conclusion of a process.

  Optionally, you can define an Implementation action to execute a connector operation, return data, or trigger a follow-up system. If no action is needed, set it to None.

  Use the Arguments section to define output values that can be passed to parent processes or used for reporting.