BPMN 2.0 Compatibility

Blank Start Event

A Blank Start Event is the most basic form of initiation. It is used when a process is intended to be started manually — typically by clicking the Start button on the deployment page. This event defines a clear and explicit entry point for the process execution without waiting for any external input or schedule.

Message Start Event

Message Start Events enable your process to start in response to an external event or message. These messages can be configured using Event Providers — a flexible mechanism in our platform that connects to various sources like webhooks, message queues, or system triggers. For more details, refer to the Events Providers section, where you'll learn how to configure and use them as process initiators.

Timer Start Event

Timer Start Events allow processes to start based on time-based conditions. Our platform supports the following three timer types:

• Date – Triggers the process at a specific date and time. The timestamp is stored using the user’s time zone.
• Duration – Delays the start of the process by a fixed duration after deployment. It requires an input in ISO 8601 duration format, such as PT30M for 30 minutes or P1D for one day.
• Cycle – Repeats the process start at regular intervals. It also follows ISO 8601 repeating interval format. For example, R/PT5M triggers the process every 5 minutes.

Abstract Task

An Abstract Task has only one attribute — its name. It does not perform any actions and serves as a placeholder in your process flow. Abstract tasks are especially useful in early design phases when you're drafting the overall structure of a process. Once the flow is defined, these placeholder tasks can be easily converted into functional Service Tasks or Receive Tasks.

Service Task

Service Tasks are the core executable units in the platform. They call backend services to perform actions — such as making HTTP requests, running data transformations, sending messages, or interacting with external systems. The set of available service tasks is continually expanding; please refer to the Services section for a full list and configuration guidelines. Service Tasks can use parameters from the current execution state or retrieve secrets and credentials securely from the project’s vault.

Receive Task

A Receive Task behaves similarly to a Message Start Event, but it is placed in the middle of the process flow. When the flow reaches a Receive Task, execution is paused until an incoming event matches the configured filters. Once a match is found, the event’s payload is saved to the execution state, allowing the process to resume.

Although filter values for the event can reference the execution state, all event subscriptions are created when the deployment is started. This means filter values must effectively come from the initial state defined at the time of deployment.

Send Task

The Send Task is designed for emitting events from within a process flow. It is particularly useful for responding to incoming external events.

Currently, it supports the HTTP Response type, which works in conjunction with the HTTP Request event from the Internet Tools Event Provider. When used together, they enable your process to receive HTTP requests and send back structured responses.

The Send Task allows you to:

• Return a custom HTTP status code
• Define response headers
• Include a response body (plain text or structured JSON)

This task ensures your workflows can engage in two-way communication with external systems, making it easier to build responsive, real-time automation with full BPMN compatibility.

Data Store

A Data Store represents a persistent data table defined by a schema within your project. It serves as a bridge between your workflow and long-term structured data storage.

File Store

A File Store represents an external file storage system (e.g., AWS S3 Bucket) defined within your project. It can be used to create new local files, download external files, and upload local files back to external storage.

Load / Save Associations

• Data Load retrieves records from the Data Store and places them into the Execution State. Filters, sorting, and record limits can be defined based on the schema.
• File Load saves a created or downloaded file handler ID into the Execution State using the specified path expression.
• Data Save writes data from the Execution State back into the Data Store, making it accessible across processes and instances.
• File Save retrieves a local file handler ID and uploads the corresponding file to external storage. Optionally, the local file can be deleted after upload.

Exclusive Gateway

The Exclusive Gateway — also known as an XOR Gateway or exclusive data-based gateway — is used to model decision points in a process. When the execution reaches this gateway, it evaluates all outgoing sequence flows in the order they are defined.

Each sequence flow can have a condition expression, written in JSON Path, which accesses values from the execution state. A condition is considered satisfied if:

• It returns a direct true value, or
• It returns a non-empty list or array

Direct false, null, or empty list results are treated as false. A sequence flow without a condition expression is considered always true.

Only one outgoing path is selected by the exclusive gateway — the first one that satisfies its condition. If no conditions evaluate to true and no default flow is defined, the process will throw a runtime exception. This type of gateway is ideal when a decision must lead to exactly one branch of execution.

Parallel Gateway

The Parallel Gateway is used to introduce concurrent execution paths in a process. Unlike the Exclusive Gateway, it does not evaluate conditions and will always activate all connected paths.

Its behavior depends on how many incoming and outgoing sequence flows it has:

• Fork: When the flow arrives at a parallel gateway with multiple outgoing sequence flows, the gateway creates a separate concurrent execution for each path. All flows are triggered simultaneously.
• Join: When multiple execution paths arrive at a parallel gateway with multiple incoming flows, the gateway waits until all active executions reach it before proceeding. Only when every required incoming flow is complete does the process move forward.

This gateway is particularly useful for performing tasks in parallel or synchronizing branches of execution before continuing.

Inclusive Gateway

The Inclusive Gateway combines elements of both the Exclusive and Parallel gateways. Like the Exclusive Gateway, it evaluates conditions on each outgoing flow using JSON Path expressions. However, instead of selecting just one path, it may follow multiple paths in parallel — any outgoing sequence flow whose condition evaluates to true will be activated concurrently.

Its behavior can be summarized as:

• Fork: All outgoing flows are evaluated, and those whose conditions are satisfied are triggered concurrently, creating a separate execution for each.
• Join: The gateway waits for only those incoming flows that were actually triggered during the fork. Unlike the Parallel Gateway, it does not wait for all possible incoming flows — only those that are part of the current execution.

This flexibility makes the Inclusive Gateway suitable for scenarios where more than one branch may be valid at the same time, but not necessarily all.

Sequence Flow

When an element is completed during process execution, all of its outgoing sequence flows are considered for execution. By default, BPMN 2.0 allows multiple sequence flows to proceed in parallel — meaning that if there are two or more outgoing flows and no gateway to control them, each will create its own separate, concurrent path of execution. This is an important distinction: parallelism is implicit unless restricted by a gateway.

Conditional Sequence Flow

A sequence flow can include a condition expression that determines whether it should be followed. These expressions are written in JSON Path and evaluated against the process execution state. A condition is considered satisfied if:

• It returns a direct true value, or
• It returns a non-empty list or array

Empty lists, null, or false values are treated as false.

When leaving a task or event, all outgoing conditional sequence flows are evaluated. If more than one condition evaluates to true, the process will follow all of them, creating multiple parallel executions. Note that this behavior differs from gateways, where the gateway type defines how multiple conditions are handled (e.g., exclusive vs. inclusive vs. parallel).

Default Sequence Flow

Most tasks and gateways can define one of their outgoing flows as the default sequence flow. This flow acts as a fallback path: it is selected only if none of the other outgoing flows are taken (i.e., if no condition expressions evaluate to true).

Importantly, any condition attached to a default sequence flow is ignored — it will always be followed if no other paths are eligible.

None Intermediate Event

A None Intermediate Event — also called a blank event — is a placeholder with no specific behavior. Like abstract tasks, it only has a name attribute and does not influence the execution flow. These events are often used during early stages of process design as visual anchors or to indicate that an event may be defined later.

Message Intermediate Event

A Message Intermediate Event waits for a specific incoming message to continue execution. Its behavior is functionally equivalent to a Receive Task, except it is used specifically in event-driven modeling. When the process reaches a message event, it pauses until an event arrives that matches the event filters. Once matched, the payload of the received message is stored in the execution state, and the process resumes from the event.

Timer Intermediate Event

A Timer Intermediate Event introduces a delay or scheduled wait within a process — similar to the Timer Start Event, but positioned mid-flow.

When execution reaches this event, a timer is started. Once the timer expires, the process continues via the outgoing sequence flow.

Timer settings include:

• Date — A specific timestamp, stored using the user’s time zone.
• Duration — A wait time defined in ISO 8601 Duration format (e.g., PT10M for 10 minutes).
• Cycle — A repeating interval defined using the ISO 8601 Repeating Intervals format (e.g., R5/PT5M for 5 repetitions every 5 minutes).

Interrupting Message Boundary Event

This event is configured the same way as a Message Intermediate Event but is attached to an activity. When a matching message is received (based on event filters), the activity is interrupted immediately. Execution continues along the outgoing sequence flow defined for the boundary event. This pattern is useful for modeling cancellations, error messages, or external signals that halt the current operation.

Non-Interrupting Message Boundary Event

Also configured like a Message Intermediate Event, but behaves differently:

When a matching message is caught, the activity continues running, and a new execution thread is created to follow the boundary event’s path. This approach is useful when the message represents a parallel concern — such as logging, notifications, or auxiliary side effects — without affecting the main task.

Interrupting Timer Boundary Event

This timer is configured like a Timer Intermediate Event, with options for a fixed date/time, duration, or recurring cycle.

If the timer fires before the activity completes, the activity is terminated, and the process flow follows the boundary event’s outgoing path. It is ideal for enforcing deadlines, timeouts, or escalation strategies.

Non-Interrupting Timer Boundary Event

Also configured like a Timer Intermediate Event, but with non-interrupting behavior:

When the timer triggers, the activity remains active, and a new concurrent execution begins from the boundary event. This can be used for sending reminders, periodic updates, or parallel monitoring activities without interfering with the main task.

End Event

A standard end event simply marks the end of a single execution path. When the process flow reaches this event, the current execution is completed.

If other branches or concurrent executions exist, they continue running independently. This type of end event is used in most situations where the goal is to complete a logical part of the process without affecting other ongoing activities.

Terminate End Event

A terminate end event is used when the goal is to completely stop the entire process instance. When any execution path reaches this event, all other active executions within the same process are immediately terminated. This is especially useful for scenarios where a critical condition is met, and continuing any other activity no longer makes sense (e.g., a fatal error, cancellation request, or successful early exit).