Process Modeling Object Descriptions

  • 54 minute(s) read

View brief descriptions about each Process modeling element that ProcessMaker Platform provides. See the BPMN 2.0 specification for more information.

Looking for Information About Connectors?

While connectors are used similarly as Process model elements in Process Modeler, connectors are not part of the BPMN 2.0 specification. Connections provide integrations with third-party services that are configured in a Process model so that ProcessMaker Platform integrates with that third-party service during Requests. See the following topics for more information:

Permissions

Your user account or group membership must have the following permissions to use Process modeling elements in Process Modeler unless your user account has the Make this user a Super Admin setting selected:

  • Processes: Edit Processes

  • Processes: View Processes

See the Process permissions or ask your Administrator for assistance.

Events

Use event-type elements to represent when a type of event occurs. These event types specify when a condition, error, message, or timer occurs in the Process. ProcessMaker Platform provides the following event-type Process model elements:

Start Event Element Types

Start Event element types start a Request for a Process when an element triggers.

Intermediate Event Element Types

Intermediate Event element types perform a variety of functions when an element triggers while its Request is in progress.

End Event Element Types

End Event element types end a Request when an element triggers.

Boundary Event Element Types

The following are boundary event type Process model elements that represent when alternative workflow routing occurs. with Form Task element, Script Task element, Manual Task element, and/or Sub Process element in the Process. Use these boundary event type Process model elements to design business solutions when expected or nominal business workflow does not occur:

Except for the Boundary Message Event element that may only be used on Sub Process elements, the remaining boundary event element types may be used in the following Process model elements and connectors:

Start Event

A Start Event element starts a Request for a Process. Note that a Start Event element does not represent an assignee because a Request has not started until a Start Event element triggers. Each Start Event element can be configured who can start a Request or via our API. A Start Event element cannot have an incoming Sequence Flow element, though it may have an outgoing Message Flow element. A Process model can have multiple Start Event elements, each representing a different user or group (or via Web entry).

Use a Start Event element to represent how a Request for that Process starts in one of the following ways:

  • The Request can be started by an authenticated user (Jane Doe) or any member of a specified group (Accounting department).

  • The Request can be started by either an anonymous or authenticated user through a published URL. This allows a Screen to be available on a public-facing Web site that starts the Request when that Screen is submitted.

  • The Request can be started via our RESTful API.

Below is a Start Event element when it has been placed into a Process model.

Start Event element

Below is a Start Event element configured to use Web Entry.

Start Event element configured to use Web Entry

See how to add and configure Start Event elements.

Start Timer Event

A Start Timer Event element starts a Request for a Process at a specified time or at a periodic interval. A Start Timer Event element cannot have an incoming Sequence Flow element. Use this element to indicate that a Request for that Process must begin at a specific date and time, such as on an employee’s employment anniversary to schedule a performance review. A Process model can have multiple Start Timer Event elements.

Below is a Start Timer Event element when it has been placed into a Process model.

Start Timer Event element

See how to add and configure Start Timer Event elements.

Signal Start Event

A Signal Start Event element starts a Request for a Process when it receives a specific broadcasting Signal designed in Signal Manager from a broadcasting element in any other Request in that ProcessMaker Platform instance. The element that broadcasts the Signal does not need to be in the same Process model as the Signal Start Event element to receive the broadcast. Pool elements within the same Process model that contain Signal Start Event elements also trigger.

The Signal Start Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when starting a Request.

The broadcasting Signal may originate from any of the following:

  • Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a Signal that contains none, part, or all of its current Request data to all Signal Start Event elements in all Processes listening for that Signal. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The Signal Start Event element references the Signal's payload when starting the new Request. Use this functionality to start different Requests simultaneously while the Request that broadcasts the Signal is in progress.

  • Signal End Event element: A Signal End Event element broadcasts a Signal that contains none, part, or all of its Request data to all Signal Start Event elements in all Processes listening for that Signal. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The Signal Start Event element references the Signal's payload when starting the new Request. Use this functionality to start a different Request when the Request that broadcasts the Signal completes.

Signal Start Event elements function as follows during a Request:

  1. All Signal Start Event elements listen for a specified broadcasting Signal.

  2. The Intermediate Signal Throw Event element or Signal End Event element triggers from a separate Request not necessarily represented in the same Process model as any Signal Start Event element.

  3. That triggering element broadcasts its Signal containing Request data.

  4. For each Signal Start Event element in any Process, if the Signal ID matches that for which it is listening for its broadcast, then that Signal Start Event element triggers, thereby starting a Request for its Process. Otherwise, the Signal is ignored for those Signal Start Event elements not listening for that Signal and those Processes do not start a Request.

Below is a Signal Start Event element when it has been placed into a Process model.

Signal Start Event element

Processes that use Signal Start Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Signal Start Event elements.

Message Start Event

A Message Start Event element starts a Request for a Process when it triggers from a specific message. The Message Start Event element listens for a message from a specified source. The purpose of the message transfer is to send data from one Pool element's Request data to another Pool element within the same Process model, thereby using the sent Request data to start a Request for the receiving Pool element; each Pool element represents its own Request with its own distinct Request data.

A Message Flow element can connect from the element sending the message to the Message Start Event element. A Process model can have multiple Message Start Event elements.

The message may originate from any of the following:

  • Intermediate Message Throw Event element: An Intermediate Message Throw Event element sends a message to the Message Start Event. Use this functionality to start a different Process's Request while the Request that sends the message is in progress. If the Message Start Event element is in the same Process model as the Intermediate Message Throw Event element for which it listens for its message, these elements must be in separate Pool elements since each Pool element has its own Request.

  • Message End Event element: A Message End Event element sends a message to the Message Start Event. Use this functionality to start a different Process's Request when the Request that sends the message completes. If the Message Start Event element is in the same Process model as the Message End Event element for which it listens for its message, these elements must be in separate Pool elements.

  • Third-party service: A third-party service such as a CRM may send a message via our API to the Message Start Event, thereby starting a Request.

A Message Start Event element functions as follows during a Request:

  1. The Message Start Event element listens for a message based on that message's name. The message name is a placeholder for the message.

  2. The Intermediate Message Throw Event element or Message End Event element triggers.

  3. That triggering element sends its message containing Request data to the Message Start Event element.

  4. If the message name matches that for which the Message Start Event element is listening, then that element triggers, thereby starting the Request. Otherwise, the message is ignored.

Below is a Message Start Event element when it has been placed into a Process model.

Message Start Event element

Processes that use Message Start Event elements can be complex. Use it to test workflow variations while designing such Processes.

See how to add and configure Message Start Event elements.

Conditional Start Event

A Conditional Start Event element starts a Request for a Process when that element's condition(s) are met to do so. The Conditional Start Event element's condition(s) can pertain to a Request's data in any Process. The Conditional Start Event element triggers when its specified conditions are met; until its conditions are met, that Conditional Start Event element does not trigger and therefore does not start a Request. Use this element to conditionally start a Request from any other Request.

A Process may use multiple Conditional Start Event elements. However, each Conditional Start Event element must use a unique condition for that element to trigger unless each Conditional Start Event element is in a separate Pool element.

Below is a Conditional Start Event element when it has been placed into a Process model.

Conditional Start Event element

Processes that use Conditional Start Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Conditional Start Event elements.

Intermediate Timer Event

An Intermediate Timer Event element pauses a Request for a Process until a specific time. When the specified time occurs, the Intermediate Timer Event element triggers, thereby resuming workflow for that Request. Use this element to cause a Request to pause until a specific time. For example, use this element to make a Request pause 30 days before checking if you receive an invoice from a customer after services are rendered.

Below is an Intermediate Timer Event element when it has been placed into a Process model.

Intermediate Timer Event element

See how to add and configure Intermediate Timer Event elements.

Intermediate Signal Catch Event

An Intermediate Signal Catch Event element pauses a Request until that element receives a specific broadcasting Signal designed in Signal Manager from a broadcasting element in any other Request. These paused Requests may be for many different Process models. The element that broadcasts the Signal does not need to be in the same Process model as the Intermediate Signal Catch Event element to receive the broadcast. Pool elements within the same Process model that contain Intermediate Signal Catch Event elements also trigger.

The Intermediate Signal Catch Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when resuming its Request.

The broadcasting Signal may originate from any of the following:

  • Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a specified Signal containing none, part, or all of its Request data to all Intermediate Signal Catch Event elements in paused Requests while the Intermediate Signal Catch Event element(s) in those Requests listens for that Signal. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The Intermediate Signal Catch Event element references the Signal's payload when resuming its Request. Use this functionality to resume workflow for potentially multiple paused Requests as soon as the Intermediate Signal Throw Event broadcasts the Signal.

  • Signal End Event element: A Signal End Event element broadcasts a specified Signal containing none, part, or all of its Request data to all Intermediate Signal Catch Event elements in paused Requests while the Intermediate Signal Catch Event element(s) in those Requests listens for that Signal. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The Intermediate Signal Catch Event element references the Signal's payload when resuming its Request. Use this functionality to resume workflow for potentially multiple paused Requests as soon as the Signal End Event element completes its Request.

Each Intermediate Signal Catch Event element functions as follows during its Request:

  1. Workflow in each Request using an Intermediate Signal Catch Event element pauses when it reaches this event. Each Intermediate Signal Catch Event element waits for a specified broadcasting Signal.

  2. The Intermediate Signal Throw Event element or Signal End Event element triggers from a separate Request not necessarily represented in the same Process model as any Intermediate Signal Catch Event element.

  3. That triggering element broadcasts its Signal containing Request data.

  4. Each Intermediate Signal Catch Event element in each paused Request that matches the broadcasting Signal triggers, thereby resuming workflow simultaneously in those Requests. Otherwise, that broadcasting Signal is ignored for those Intermediate Signal Catch Event elements not listening for that Signal and those Requests remain paused.

Below is an Intermediate Signal Catch Event element when it has been placed into a Process model.

Intermediate Signal Catch Event element

Processes that use Intermediate Signal Catch Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Intermediate Signal Catch Event elements.

Intermediate Signal Throw Event

An Intermediate Signal Throw Event element broadcasts a specific Signal designed in Signal Manager that contains none, part, or all of its current Request data when it triggers to all elements throughout that ProcessMaker Platform instance. Any element listening for that specific Signal thereby triggers. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The element that listens for that broadcasting Signal does not need to be in the same Process model as the Intermediate Signal Throw Event element. Pool elements in the same Process model that contain elements listening for that Signal also trigger.

The purpose of the broadcasting Signal may be the following:

  • Signal Start Event element: Broadcast a specific Signal to all Signal Start Event elements listening for that Signal to simultaneously start Requests for those Processes. The Signal Start Event element references the Signal's payload when starting the new Request.

  • Intermediate Signal Catch Event element: Broadcast a specific Signal to all Intermediate Signal Catch Event elements listening for that Signal to simultaneously resume workflow for those Requests that have been paused. Each triggered Intermediate Signal Catch Event element references the Signal's payload when resuming its Request.

  • Boundary Signal Event: Broadcast a specific Signal to all Boundary Signal Event elements listening for that Signal to follow alternative workflow from its associating element or connector. Each triggered Boundary Signal Event element references the Signal's payload when taking alternative workflow in its Request.

An Intermediate Signal Throw Event element functions as follows during a Request:

  1. The Intermediate Signal Throw Event element triggers.

  2. The Intermediate Signal Throw Event element broadcasts its specified Signal.

  3. If the element is listening for that broadcasted Signal, then that listening element triggers. Otherwise, the Signal is ignored.

Below is an Intermediate Signal Throw Event element when it has been placed into a Process model.

Intermediate Signal Throw Event element

Processes that use Intermediate Signal Throw Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Intermediate Signal Throw Event elements.

Intermediate Message Catch Event

An Intermediate Message Catch Event element pauses a Request until that element receives a specific message. The purpose of the message transfer is to send data between Requests running from the same Process model since each Pool element represents its own Request with its own distinct Request data.

The message may originate from any of the following:

  • Intermediate Message Throw Event element: An Intermediate Message Throw Event element sends a message to the Intermediate Message Catch Event element that has paused its in-progress Request until the Intermediate Message Catch Event element receives its message. Use this functionality to resume workflow to the Request using the Intermediate Message Catch Event element from another Request. If the Intermediate Message Catch Event element is in the same Process model as the Intermediate Message Throw Event element for which it listens for its message, these elements must be in separate Pool elements since each Pool element has its own Request.

  • Message End Event element: A Message End Event element sends a message to the Intermediate Message Catch Event. Use this functionality to resume workflow to the Process Request using the Intermediate Message Catch Event element when the Request that sends the message completes. If the Intermediate Message Catch Event element is in the same Process model as the Message End Event element for which it listens for its message, these elements must be in separate Pool elements.

  • Third-party service: A third-party service such as a CRM may send a message via our API to the Intermediate Message Catch Event, thereby resuming workflow for that Request.

A Message Flow element can connect from the element sending the message to the Intermediate Message Catch Event element. Ensure that Intermediate Message Catch Event element and its triggering element are in different Pool elements. When configuring the Intermediate Message Catch Event element during Process modeling, select which message from the triggering element sends to the Intermediate Message Catch Event element.

An Intermediate Message Catch Event element functions as follows during a Request:

  1. Workflow in the Request using the Intermediate Message Catch Event element pauses when it reaches this event. The Intermediate Message Catch Event element waits for a message based on that message's name. The message name is a placeholder for the message.

  2. The Intermediate Message Throw Event element or Message End Event element triggers.

  3. That triggering element sends its message containing Request data to the Intermediate Message Catch Event element.

  4. If the message name matches that for which the Intermediate Message Catch Event element is listening, then that element triggers; workflow resumes in that Request. Otherwise, the Intermediate Message Catch Event element ignores the message.

Consider the following example how the Intermediate Message Catch Event element functions. This example uses the Intermediate Message Throw Event element in an overly simple purchase request and order fulfillment Process model. The Process model contains two Processes, each within its own Pool element. Each Process may potentially run its own Request.

Simple Process model example to demonstrate how an Intermediate Message Catch Event functions

The Intermediate Message Catch Event element (labeled "Catch from Order") is in the second Pool, "Purchase Fulfillment."

After the "Purchase Fulfillment" Request starts, the following occurs:

  1. Workflow delays after the "Preparation" Form Task element.

  2. When the Intermediate Message Throw Event element triggers from the "Purchase Order" Request (labeled "Throw to Fulfillment"), it sends its message to the Intermediate Message Catch Event element in the "Purchase Fulfillment" Request. Workflow continues in the "Purchase Order" Request to the End Event element.

  3. In the "Purchase Fulfillment" Request, the Intermediate Message Catch Event element triggers and receives the Intermediate Message Throw Event element's message.

  4. Workflow resumes in the "Purchase Fulfillment" Request.

Below is an Intermediate Message Catch Event element when it has been placed into a Process model.

Intermediate Message Catch Event element

Processes that use Intermediate Message Catch Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Intermediate Message Catch Event elements.

Intermediate Message Throw Event

An Intermediate Message Throw Event element sends a message to a Message Start Event or an Intermediate Message Catch Event element. The purpose of the message transfer is to send data between Requests running from the same Process model since each Pool element represents its own Request with its own distinct Request data.

A Message Flow element can connect from the Intermediate Message Throw Event element to the element listening for its message.

An Intermediate Message Throw Event element functions as follows during a Request:

  1. The Intermediate Message Throw Event element triggers.

  2. The Intermediate Message Throw Event element sends its message. The message has a name which is a placeholder for the Request data it sends to the catching element.

  3. If the message name matches that for which the catching element is listening, then that element triggers. Otherwise, the message is ignored.

See the Intermediate Message Catch Event element description for a simple example how an Intermediate Message Throw Event element works.

Below is an Intermediate Message Throw Event element when it has been placed into a Process model.

Intermediate Message Throw Event element

Processes that use Intermediate Message Throw Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Intermediate Message Throw Event elements.

Intermediate Conditional Catch Event

An Intermediate Conditional Catch Event element pauses a Request until specified conditions in that Request are met. An Intermediate Conditional Catch Event element only triggers when the specified condition(s) in that Request are met, thereby allowing workflow to route through its outgoing Sequence Flow element(s). Otherwise, that Request remains paused indefinitely unless the Process model provides an alternative for workflow routing. Use an Intermediate Conditional Catch Event element to design workflow routing to occur only when specific business conditions occur.

Below is an Intermediate Conditional Catch Event element when it has been placed into a Process model.

Intermediate Conditional Catch Event element

Processes that use Intermediate Conditional Catch Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Intermediate Conditional Catch Event elements.

End Event

An End Event element completes a Request for a Process. An End Event element cannot have an outgoing Sequence Flow element. A Process model can have multiple End Event elements.

Below is an End Event element when it has been placed into a Process model.

End Event element

See how to add and configure End Event elements.

Message End Event

A Message End Event element sends a message to a Message Start Event or an Intermediate Message Catch Event element when the Request using the Message End Event element completes. The purpose of the message transfer is to send data between Requests running from the same Process model since each Pool element represents its own Request with its own distinct Request data.

A Message Flow element can connect from the Message End Event element to the element listening for its message.

A Message End Event element functions as follows during a Request:

  • The Message End Event element triggers when the Request using it completes.

  • The Message End Event element sends its message. The message has a name which is a placeholder for the Request data it sends to the catching element.

  • If the message name matches that for which the catching element is listening, then that element triggers. Otherwise, the message is ignored.

Below is a Message End Event element when it has been placed into a Process model.

Message End Event element

Processes that use Message End Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Message End Event elements.

Error End Event

An Error End Event element records the error before that Request completes if an error occurs. The purpose of sending the error is to provide an alternate business solution if expected workflow routing encounters an error.

Use an Error End Event element in the following ways:

  • In a Pool element: If an Error End Event element records an error during a Request within a Pool element (or the Process model does not use a Pool element), that Request completes but shows the error in the Completed Request summary. If a Process model contains more than one Pool element, the Error End Event element does not affect workflow for the Request(s) in the other Pool element(s). Use an Error end Event element when that Process model is called from a parent Process via a Sub Process element.

  • In a child Process called from a parent Process's Sub Process element: If an Error End Event element records an error during a Request for a child Process called from a parent Process's Sub Process element, that error is sent to the Sub Process element when the child Process's Request completes. One of the following occurs:

    • The Sub Process element has an associated Boundary Error Event element: Workflow in the parent Process's Request routes through the Boundary Error Event element. If the Boundary Error Event element is not configured to interrupt workflow, workflow also resumes as if the error had not occurred in the child Request (thereby creating parallel workflow in the parent Request). Use this Process design to handle errors from the child Request.

    • The Sub Process does not have an associated Boundary Error Event element: Workflow resumes in the parent Process's Request as if the error had not occurred in the child Request.

Below is an Error End Event element when it has been placed into a Process model.

Error End Event element

See how to add and configure Error End Event elements.

Signal End Event

A Signal End Event element broadcasts a specific Signal designed in Signal Manager that contains none, part, or all of its Request data when it triggers to all elements throughout that ProcessMaker Platform instance. Any element listening for that specific Signal thereby triggers. The Signal End Event element triggers when its Request completes. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The element that listens for that broadcasting Signal does not need to be in the same Process model as the Signal End Event element. Pool elements in the same Process model that contain elements listening for that Signal also trigger.

The purpose of the broadcasting Signal may be the following:

  • Signal Start Event element: Broadcast a specific Signal to all Signal Start Event elements listening for that Signal to simultaneously start Requests for those Processes. The Signal Start Event element references the Signal's payload when starting the new Request.

  • Intermediate Signal Catch Event element: Broadcast a specific Signal to all Intermediate Signal Catch Event elements listening for that Signal to simultaneously resume workflow for those Requests that have been paused. Each triggered Intermediate Signal Catch Event element references the Signal's payload when resuming its Request.

  • Boundary Signal Event: Broadcast a specific Signal to all Boundary Signal Event elements listening for that Signal to follow alternative workflow from its associating element or connector. Each triggered Boundary Signal Event element references the Signal's payload when taking alternative workflow in its Request.

A Signal End Event element functions as follows during a Request:

  1. The Signal End Event element triggers, thereby completing its Request.

  2. The Signal End Event element broadcasts its specified Signal.

  3. If the element is listening for that broadcasted Signal, then that listening element triggers. Otherwise, the Signal is ignored.

Below is a Signal End Event element when it has been placed into a Process model.

Signal End Event element

Processes that use Signal End Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Signal End Event elements.

Terminate End Event

A Terminate End Event element immediately terminates a Request for a Process as well as any child Request(s) that (parent) Request started via Sub Process element(s). A Terminate End Event element cannot have an outgoing Sequence Flow element. A Process model can have multiple Terminate End Event elements.

Consider the following Process as an example to distinguish between an End Event element and a Terminate End Event element.

The Terminate End Event unexpectedly aborts all workflow(s) in that Request when it triggers

If the End Event element labeled "End Event A" triggers, its workflow ends. However, the workflow that routes through the Form Task element labeled "Task B" may continue to the End Event element labeled "End Event B."

If the Terminate End Event element triggers, then all workflows occurring during that Request unexpectedly end.

Below is a Terminate End Event element when it has been placed into a Process model.

Terminate End Event element

See how to add and configure Terminate End Event elements.

Boundary Timer Event

A Boundary Timer Event element represents alternate workflow routing when a specified amount of time expires from the moment its associating element or connector triggers. The Boundary Timer Event element may associate with any of the following elements and connectors:

The Boundary Timer Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Timer Event element associates with a Form Task element.

Boundary Timer Event element associates with a Form Task element

During an in-progress Request, if the element/connector to which the Boundary Timer Event associates has triggered but is not yet complete and the specified time expires for which the Boundary Timer Event element is set, then workflow routes through the Boundary Timer Event element.

After the associating element/connector triggers, the Boundary Timer Event element starts the set timer but does not trigger. The Boundary Timer Event element triggers only after the set time expires and its associating element has not completed.

Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Timer Event element if triggers.

Use a Boundary Timer Event element to design business solutions when intended or best-case workflow in your Request does not occur in an expected period of time. Consider these examples:

  • Escalate Task problems: When a Task assignee does not complete a Task when it is due, escalate to that assignee's manager to ensure project tasks are completed on schedule.

  • Script fail-safe: If a Script does not complete in a period of time, route workflow to a system administrator to investigate why the Script provided no response.

  • Escalate child sub-process problems: If the Request for a child Sub Process does not complete in a required period of time, route workflow to a manager's Task in the parent Process's Request so that the child Request does not delay the parent Request.

An element or connector associated with a Boundary Timer Event element may also associate with the following elements in the same element/connector:

A Sub Process element associated with a Boundary Timer Event may also associate with a Boundary Message Event element.

Configure whether a Boundary Timer Event element interrupts the best-case scenario workflow:

  • Interrupting workflow: When workflow routes through the Boundary Timer Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Timer Event element if the Manual Task element does not complete within 30 minutes.

  • Non-interrupting workflow: Workflow routes both through the Boundary Timer Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Timer Event element if the Manual Task element does not complete within 30 minutes; however, workflow also routes through the best-case scenario when the Manual Task element completes.

Processes that use Boundary Timer Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Boundary Timer Event elements.

Boundary Error Event

A Boundary Error Event element represents alternate workflow routing when an error occurs with its associating element or connector. The Boundary Error Event element may associate with any of the following elements and connectors:

The Boundary Error Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Error Event element associates with a Script Task element.

Boundary Error Event element associates with a Script Task element

During an in-progress Request, if the element/connector to which the Boundary Error Event associates has triggered but is not yet complete when any of the following occurs, then workflow routes through the Boundary Error Event element:

  • An error occurs in the associating element/connector.

  • The Boundary Error Event element associates with a Sub Process element and that element receives an error from its child Request.

If the element/connector to which the Boundary Error Event element associates has not triggered, then the Boundary Error Event element does not trigger when the error occurs. The Boundary Error Event element may only trigger if the error occurs in its associating element/connector.

Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Error Event element if it triggers.

Use a Boundary Error Event element to design business solutions when intended or best-case workflow does not occur because of a Request error. Consider these examples:

  • Technical error with a Script: If a running Script returns an error, route workflow to a system administrator's Task to investigate why the Script failed.

  • Escalate child sub-process problems: If the Error End Event element in a child Request captures a Request error, the Boundary Error Event element associated with the parent Request's Sub Process element receives the error, then routes workflow to a system administrator's Task in the parent Process's Request to investigate the issue in the child Request.

An element or connector associated with a Boundary Error Event element may also associate with the following elements in the same element/connector:

A Sub Process element associated with a Boundary Error Event may also associate with a Boundary Message Event element.

Below is a Boundary Error Event element when it is associates with a Script Task element.

Boundary Error Event element associates with a Script Task element

Processes that use Boundary Error Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Boundary Error Event elements.

Boundary Signal Event

A Boundary Signal Event element represents alternate workflow routing when that element receives a specific broadcasting Signal designed in Signal Manager. The Boundary Signal Event may associate with any of the following elements and connectors:

The Boundary Signal Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Signal Event element associates with a Form Task element.

Boundary Signal Event element associates with a Form Task element

During an in-progress Request, if the element/connector to which the Boundary Signal Event associates has triggered but is not yet complete and the Boundary Signal Event element receives the broadcasting Signal for which it listens, then workflow routes through the Boundary Signal Event element. The element that broadcasts the Signal does not need to be in the same Process model as the Boundary Signal Event element to receive the broadcast Signal. If the broadcasting Signal is in a different Pool element within the same Process model, the Boundary Signal Event also triggers.

The Boundary Signal Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when routing its Request.

If the element/connector to which the Boundary Signal Event element associates has not triggered when the Signal broadcasts, then the Boundary Signal Event element does not trigger.

Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Signal Event element if it triggers.

Use a Boundary Signal Event element to design business solutions when alternate workflow must occur in multiple Requests, even if those Requests derive from separate Processes. Consider these examples:

  • Escalate multiple Requests simultaneously to higher management: Use an Intermediate Signal Throw Event element to broadcast a specific signal to indicate that higher management needs to participate in multiple separate Requests simultaneously: when all Boundary Signal Event elements receive the specific Signal, workflow routes to alternate Task assignees to escalate a problem in each separate Request.

  • Broadcast a Signal when a separate Request completes: When a separate Request completes, a Signal End Event element broadcasts a specific Signal that indicates that Request's completion. All Boundary Signal Event elements from all in-progress Requests trigger simultaneously to route through alternate workflow. This design may be a business solution to indicate work on multiple Requests may not be necessary and workflow may route to end each of those Requests simultaneously.

  • Broadcast a Signal from a child sub-process: If during a Request for a child Sub Process broadcasts a Signal from an Intermediate Signal Throw Event or Signal End Event element, all Boundary Signal Event elements from all in-progress Requests trigger simultaneously to route through alternate workflow.

An element or connector associated with a Boundary Signal Event element may also associate with the following elements in the same element/connector:

A Sub Process element associated with a Boundary Signal Event may also associate with a Boundary Message Event element.

Configure whether a Boundary Signal Event element interrupts the best-case scenario workflow:

  • Interrupting workflow: When workflow routes through the Boundary Signal Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Signal Event element if the Boundary Signal Event element receives the specific broadcasting Signal for which it is listening.

  • Non-interrupting workflow: Workflow routes both through the Boundary Signal Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Signal Event element while the Form Task element is in progress; however, workflow also routes through the best-case scenario when the Form Task element completes.

Processes that use Boundary Signal Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Boundary Signal Event elements.

Boundary Message Event

A Boundary Message Event element represents alternate workflow routing when its associating element or connector receives a specific message as designated by the message's name. The associating element/connector must have triggered at the moment it receives the message. The Boundary Message Event element may associate with any of the following elements or connectors:

The Boundary Message Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Message Event element associates with a Sub Process element.

Boundary Message Event element associates with a Sub Process element

During an in-progress Request, the Boundary Message Event element may trigger in the following circumstances:

  1. The Boundary Message Event element associates with an element or connector.

  2. The Boundary Message Event element receives a specified message, designated by the message's unique name, prior to the associating element/connector triggering or completing.

  3. The Boundary Message Event element triggers. Either of the following may occur depending on if the Boundary Message Event element is configured to be "interrupting" or "non-interrupting":

    • Interrupting: If the Boundary Message Event element is configured to be interrupting, its associating element/connector never triggers in that Request. Workflow routes through the Boundary Message Event element.

    • Non-interrupting: If the Boundary Message Event element is configured to be non-interrupting, the associating element/connector may potentially trigger in that Request if workflow routes to it. However, the Boundary Message Event element triggers when it receives its message, which may be temporally a different time than when the associating element/connector may trigger. If the associating element/connector triggers and completes, workflow routes through it. Both workflows may possible occur.

Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Message Event element if it triggers.

Use a Boundary Message Event element to design business solutions that adjust workflow routing from the best-case scenario. Consider these examples:

  • Boundary Message Event element receives message from another Pool element: Use an Intermediate Message Throw Event element that is in one Pool element to send a message to a Boundary Message Event element in a second Pool element. Each Pool element contains independent workflow: each is a separate Request. The Boundary Message Event element receives Request data from the Intermediate Message Throw Event element's Request. The Boundary Message Event element's Request resumes with Request data from the other Request.

  • Two elements listen for different messages: Associate a Boundary Message Event element with an Intermediate Message Catch Event element. Each of these elements listen for a different message, thereby providing two workflow routing options from this junction in the Process model.

An element or connector associated with a Boundary Message Event element may also associate with the following elements in the same element/connector:

Configure whether a Boundary Message Event element interrupts the best-case scenario workflow:

  • Interrupting workflow: When workflow routes through the Boundary Message Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Message Event element if that element receives a message from the child Request.

  • Non-interrupting workflow: Workflow routes both through the Boundary Message Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Message Event element if that element receives a message from the child Request; however, after the child Request completes and workflow resumes in the parent Request, the Sub Process element completes and routes through the best-case scenario.

Processes that use Boundary Message Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Boundary Message Event elements.

Boundary Conditional Event

A Boundary Conditional Event element represents alternate workflow routing when the Boundary Conditional Event element evaluates specified Request conditions have occurred at the moment its associating element or connector triggers. The Boundary Conditional Event element may while associate with any of the following elements and connectors:

The Boundary Conditional Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Conditional Event element associates with a Form Task element.

Boundary Conditional Event element associates with a Form Task element

During an in-progress Request, if the element/connector to which the Boundary Conditional Event associates has triggered but is not yet complete and the Boundary Conditional Event element's condition is met, then workflow routes through the Boundary Conditional Event element.

If the element/connector to which the Boundary Conditional Event element associates has not triggered, then the Boundary Conditional Event element does not trigger regardless of the Boundary Conditional Event element's conditions.

Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Conditional Event element if it triggers.

Use a Boundary Conditional Event element to design business solutions for nuanced business conditions in your business solution. Consider these examples:

  • Evaluate if a purchase receipt is required: A PDF Generator connector can generate a PDF for a receipt in a purchase-related Process. Associate a Boundary Conditional Event element with the PDF Generator connector to evaluate if the connector generates a Screen of the receipt based on a Request variable value the purchasing agent has previously selected to indicate if a receipt is required.

  • Evaluate if enrolled courses are valid prior to payment: A university student's Form Task element triggers to pay for course enrollments that semester. Associate that Form Task element with a Boundary Conditional Event element to evaluate if all enrolled courses are still valid at the time of payment: if any enrolled course offering or schedule has changed, route to a Send Email connector to send an email to that student notifying of course changes prior to payment.

An element or connector associated with a Boundary Conditional Event element may also associate with the following elements in the same element/connector:

A Sub Process element associated with a Boundary Conditional Event may also associate with a Boundary Message Event element.

Configure whether a Boundary Conditional Event element interrupts the workflow when this element's specified Request conditions are met:

  • Interrupting workflow: When workflow routes through the Boundary Conditional Event element, workflow is interrupted and does not route through the default scenario route. As highlighted in the example below, workflow routes through the Boundary Conditional Event element if this element's specified Request conditions are met.

  • Non-interrupting workflow: Workflow routes both through the Boundary Conditional Event element and the default scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Conditional Event element if this element's specified Request conditions are met; however, workflow also routes through the default scenario when the Manual Task element completes.

Processes that use Boundary Conditional Event elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Conditional Boundary Event elements.

Tasks

Tasks represent activities performed by persons in ProcessMaker Platform, offline (such as in the physical environment), or by a Script. ProcessMaker Platform provides the following Task-type Process model elements:

Form Task

A Form Task element represents an activity a person performs while participating in a Request via ProcessMaker Platform. A Form Task element is different than a Manual Task element in which a person performs an activity in the physical environment. Assign the Task that the Form Task element represents to any of the following types of Request participants:

  • The user who started the Request, referred to as the Request starter.

  • A specific user

  • Any member of a specified group

  • The previous Task assignee in that Request's workflow

People perform Task activities through Screens as digital forms and displays. Screens are designed in Screens Builder.

Below is a Form Task element when it has been placed into a Process model.

Form Task element

See how to add and configure Form Task elements.

Manual Task

A Manual Task element represents an activity a person performs offline and/or in the physical environment such that ProcessMaker Platform cannot monitor its activity. A Manual Task element is different than a Form Task element, in which a person performs an activity via a Screen. ProcessMaker Platform relies on the Task assignee to acknowledge completion of that activity. An example of a Manual Task activity is moving physical merchandise in a warehouse: this activity occurs offline and is one which does not involve ProcessMaker Platform interaction.

Below is a Manual Task element when it has been placed into a Process model.

Manual Task element

See how to add and configure Manual Task elements.

Script Task

A Script Task element represents an activity performed by a Script. Use Scripts in the following ways:

  • Interact with legacy systems in your organization such as ERPs and CRMs.

  • Connect with third-party services like Adobe DocuSign, Amazon Textract, and APIs as well as Robotic Process Automations (RPAs) like UiPath.

See an example in the following video how ProcessMaker Platform integrates with third-party services Amazon Textract and UiPath Robotic Process Automation (RPA) so a loan application workflow scans, analyzes, and intelligently routes a Request and provision a bot accordingly.

  • Intended audience: Process designers and business analysts

  • Viewing time: 11 minutes; contains narration

Script Tasks integrate with third-party services and RPAs in a Process demonstration

Scripts are designed in Script Editor. Scripts are independent of Process models: any Script can be reused in any Process model in your organization. This architecture allows Process Owners to focus on Process modeling in a no-code environment while ProcessMaker Developers develop reusable Scripts. Scripts can leverage Screens variable values for in-progress Requests.

Below is a Script Task element when it has been placed into a Process model.

Script Task element

See how to add and configure Script Task elements.

Sub Process

A Sub Process element calls a Sub Process that can be re-used by other Processes. The Sub Process that the Sub Process element calls is referred to as the "child" Sub Process and must be an external Process from the calling Process it (referred to as the "parent" Process).

The child Sub Process that the Sub Process element calls from the parent Process's Request must be in the same ProcessMaker Platform instance and not archived.

The child Sub Process has its own Request. The Request for the parent Process waits until the child Sub Process's Request completes before its workflow continues. When the child Sub Process's Request completes, the parent Process's Request continues from the Sub Process element.

To prevent routing for the parent Process's Request from waiting until the child Sub Process's Request completes, use a Parallel Gateway element preceding the Sub Process element. Use a parallel outgoing Sequence Flow element from the Parallel Gateway element to continue routing the parent Process while the Sub Process element waits for the child Sub Process's Request to complete.

Below is a Sub Process element when it has been placed into a Process model.

Sub Process element

See how to add and configure Sub Process elements.

Gateways

Gateway elements route Request workflow in the following ways:

Exclusive Gateway

An Exclusive Gateway element evaluates a Request's workflow routing conditions for a Process. These routing conditions are configured on each outgoing Sequence Flow element from the Exclusive Gateway element. When a Request is in progress and the Exclusive Gateway element triggers, each of its outgoing Sequence Flow elements' conditions are evaluated to determine which single Sequence Flow element workflow routes for that Request. Unlike the Inclusive Gateway element, only one Sequence Flow element can trigger from the Exclusive Gateway element to route workflow.

Use an Exclusive Gateway element when you want only one condition to pass. Otherwise, consider using an Inclusive Gateway element whereby any conditions that pass specified conditions allow workflow routing to continue.

Below is an Exclusive Gateway element when it has been placed into a Process model.

Exclusive Gateway element

Processes that use Exclusive Gateway elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See the following topics about Exclusive Gateway elements:

Inclusive Gateway

An Inclusive Gateway element functions in two different ways, but not at the same time from the same element:

  • Converging workflow (synchronize workflow): An Inclusive Gateway element may synchronize Request workflow from two or more incoming Sequence Flow elements to the Inclusive Gateway element. All incoming Sequence Flow elements converging to the Inclusive Gateway element must trigger before the Inclusive Gateway element triggers, thereby synchronizing a Request's workflow. Use this coordinate workflow.

  • Diverging workflow (evaluate routing conditions): An Inclusive Gateway element may also evaluate a Request's workflow routing conditions for a Process. These routing conditions are configured on each outgoing Sequence Flow element from the Inclusive Gateway element. When a Request is in progress and the Inclusive Gateway element triggers, each of its outgoing Sequence Flow elements' conditions are evaluated to determine which Sequence Flow element(s) continue routing for that Request. Unlike the Exclusive Gateway element, multiple Sequence Flow elements can trigger from the Inclusive Gateway element, thereby causing multiple workflow routes simultaneously for the same Request that stem from that Inclusive Gateway element. Use an Inclusive Gateway element when you potentially want multiple workflow routes to occur simultaneously in that Request. Otherwise, consider using an Exclusive Gateway element to allow only one Sequence Flow element's condition(s) to continue workflow route for that Request.

One Inclusive Gateway element can only converge or diverge workflow, but not both. Use two Inclusive Gateway elements to both converge and diverge workflow.

Use two Inclusive Gateway elements for both converging and diverging workflow

Below is an Inclusive Gateway element when it has been placed into a Process model.

Inclusive Gateway element

Processes that use Inclusive Gateway elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See Add and Configure Inclusive Gateway Elements.

Parallel Gateway

A Parallel Gateway element synchronizes Request workflow for a Process by converging or diverging parallel Sequence Flow elements. The Parallel Gateway element has two separate functions, but not at the same time from the same element:

  • Converging workflow: Converging workflow represents two or more incoming Sequence Flow elements to the Parallel Gateway element. All incoming Sequence Flow elements converging to the Parallel Gateway element must trigger before the Parallel Gateway element triggers, thereby synchronizing a Request's workflow. Use this coordinate workflow.  

  • Diverging workflow: Diverging workflow represents two or more outgoing Sequence Flow elements from the Parallel Gateway element. When a Parallel Gateway triggers, all outgoing Sequence Flow elements from the gateway element trigger simultaneously without exception. Conditions cannot be placed on any outgoing Sequence Flow elements from the Parallel Gateway element. Use this when multiple workflow routes must occur simultaneously.  

One Parallel Gateway element can only converge or diverge workflow, but not both. Use two Parallel Gateway elements to synchronize both converging and diverging parallel workflow.  

Use two Parallel Gateway elements for both converging and diverging parallel workflow

Below is a Parallel Gateway element when it has been placed into a Process model.

Parallel Gateway element

Processes that use Parallel Gateway elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Parallel Gateway elements.

Event-Based Gateway

An Event-Based Gateway element evaluates a Request's workflow routing for a Process based on which event occurs immediately after the Event-Based Gateway element. Follow these guidelines to use the Event-Based Gateway element:

  • The Event-Based Gateway element requires two or more outgoing Sequence Flow elements. When evaluating events, workflow routes through only one Sequence Flow element; multiple events cannot pass simultaneously from one Event-Based Gateway element during a Request.

  • The Event-Based Gateway element can only connect with Intermediate Timer Event or Intermediate Message Catch Event elements. This creates the scenario that either a timed event occurs or an Intermediate Message Catch Event element receives a message.

When the Event-Based Gateway element triggers during a Request, workflow for that Request pauses. ProcessMaker Platform then evaluates the events immediately following the Event-Based Gateway element's via its outgoing Sequence Flow elements and waits until one of those events occur. Request workflow resumes by routing to the event that occurs first.

Consider the following example. Suppose that you have a Process that monitors if you receive package shipments on time. Use an Event-Based Gateway element to monitor which event occurs next. Refer to the Process modeling elements below.

Event-Based Gateway element example

In this example, connect the following Process modeling elements from the Event-Based Gateway element:

  • Intermediate Timer Event element: The first connecting event from the Event-Based Gateway element is an Intermediate Timer Event element that is set to 24 hours. This event represents a 24-hour period in which presumably a notification has not arrived that the package shipped within that time period. If the timer set in the Intermediate Timer Event expires, then workflow routes to a Manual Task element in which its assignee telephones the shipping company.

  • Intermediate Message Catch Event element: The second connecting element is an Intermediate Message Catch Event element that represents a notification of the package’s shipment presumably before the timer set in the Intermediate Timer Event element expires. If the Intermediate Message Catch Event element triggers, then the notification was received before the 24-hour period expired. No further action is required.

Below is an Event-Based Gateway element when it has been placed into a Process model.

Event-Based Gateway element

Processes that use Event-Based Gateway elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Event-Based Gateway elements.

Organize Process Participants and Roles

BPMN 2.0 provides graphical representations to organize participants and roles in a Process model.

Pool

A Pool element represents an organization or entity involved in a Process model. The Pool element might represent a specific role ("Human Resources"), entity (such as a company) or a general relationship (such as a buyer, seller, or manufacturer).

Each Pool element represents its own Request, and therefore its own Request data. While a Process model can have multiple Pool elements, each Pool element represents its own Request with distinct Request data.

Below is a Pool element when it has been placed into a Process model. "New Pool" is the name of the Pool element.

Pool element containing a modeled Process

Processes that use multiple Pool elements can be complex. Therefore, use it to test workflow variations while designing such Processes.

See how to add and configure Pool elements.

Lane

A Lane element represents a partition within a Pool element. Each Lane element indicates a role, actor, or participant within the Pool element. Text within the Lane element indicates the participant in the Process model. Any elements within the Lane element indicate that the participant is the actor or is responsible for performing actions in the Process model. Furthermore, Sequence Flow elements between elements in other Pool or Lane elements indicate with which other Process participants that Lane element interacts.

Below is a Pool element that contains three Lane elements when it has been placed into a Process model: "Requester," "Approval," and "Requisition" from top to bottom in the Pool element. Each Lane element indicates roles within the overall Process.

Pool element with three Lane elements that indicate roles within the Process

See how to add and configure Lane elements.

Annotations and Associations

ProcessMaker Platform provides the following Process model elements that are for visual representation only:

Text Annotation

A Text Annotation element is human-readable text in a Process model that provides description about the Process. Text Annotation elements perform no functional role in Process Requests or workflow routing, but are used for visual representation only.

Below is a Text Annotation element when it has been placed into a Process model.

Text Annotation element

See how to add and configure Text Annotation elements.

Association

An Association element is part of a Text Annotation element that graphically references the Process model element that the Text Annotation element describes. Multiple Association elements can be used from one Text Annotation element. However, a Text Annotation element must be placed into the Process model before an Association element can be used.

Each Annotation element can display a directional arrow to and/or from the Text Annotation element.

Below is an Association element when it has been placed into a Process model.

Association element that references the Text Annotation element to the element it describes

See how to add and configure Association elements.

Data Object

A Data Object element is a human-readable element highlighting the flow of data in a Process. Data Object elements perform no functional role in Process Requests or workflow routing, but are used for visual representation only. These elements typically represent data in physical or digital documents that may be accessible in a Request. Use the Data Object element to highlight data that is available only while a Process Request is in progress, but is not to be stored permanently.

Below is a Data Object element when it has been placed into a Process model.  

Data Object element

See how to add and configure Data Object elements.

Data Store

A Data Store element is a human-readable element highlighting the storage of data in a Process. Data Store elements perform no functional role in Process Requests or workflow routing, but are used for visual representation only. Use the Data Store element to highlight data that is saved permanently in external or internal data stores and remains available even after a Process Request completes.

Below is a Data Store element when it has been placed into a Process model.  

Data Store element

See how to add and configure Data Store elements.

Data Association Flow

A Data Association Flow element is part of a Data Object and Data Store element that shows the flow of data between that element and other Process model elements. These elements perform no functional role in Process Requests or workflow routing, but are used for visual representation only. Sequence Flow elements and Message Flow elements affect workflow.

Multiple Data Association Flow elements can be used from one Data Object or Data Store element. However, a Data Object or a Data Store element must be placed into the Process model before a Data Association Flow element can be used.

Each Data Association Flow element can display a directional arrow to and/or from a Data Object or a Data Store element.

Below is a Data Association Flow element when it has been placed into a Process model.  

Data Association Flow element that indicates flow of data from a Form Task element

See how to add and configure Data Association Flow elements.

Flow Indicators That Affect Workflow

Flow indicators represent the order in which workflow routing, data flow and messaging occur in a Process model. ProcessMaker Platform provides the following Process model elements that indicate workflow:

Though Data Association Flow elements are flow indicators, they do not affect workflow routing, but are used for visual representation only.

Sequence Flow

Sequence Flow elements connect Process model elements to represent the intended workflow routing in a Process model. Process workflow is the order in which elements trigger or activate in a Process model. Sequence Flow elements are not to be confused with Message Flow elements.

As a best practice, indicate a consistent direction of Sequence Flow elements: either left to right or top to bottom, to make Process models easier to understand.

The Flow indicator displays when you click an element or connector in the Process model. ProcessMaker Platform knows whether to use an outgoing Sequence Flow or Message Flow element depending on the selected element or connector selected and its context within the Process model.

Flow indicator (highlighted) on a selected Process model element

Text annotations, Pool, and Lane elements do not use Sequence Flow elements. Furthermore, Sequence Flow elements cannot connect between Process model elements that are in different Pool elements since Pool elements represent different Requests. However, use Message Flow elements to transfer Request data between elements in different Pool elements.

Sequence Flow elements from Exclusive Gateway and Inclusive Gateway elements can be configured to specify under which condition(s) Request workflow routes through that Sequence Flow element. See Connect Sequence Flow Elements to Indicate Workflow Routing.

Start Event, Start Timer Event, Signal Start Event, Message Start Event, and Conditional Start Event elements begin Request workflow in Process design. Therefore, these elements cannot have incoming Sequence Flow elements.

End Event, Message End Event, Error End Event, Signal End Event, and Terminate End Event elements terminate Request workflow in Process design. Therefore, these elements cannot have outgoing Sequence Flow elements.

The Sequence Flow element indicates in which order workflow routing occurs between two connected Process model elements. Below are two Process model elements connected to infer workflow order.

Process model elements connected by a Sequence Flow element infers the order of workflow

See Set and Delete Sequence Flow Between Elements.

Message Flow

In a Process model, Message Flow elements represent messaging between elements of (or within) one Pool element to elements of (or within) another Pool element. Message Flow elements cannot connect to Process model elements within the same Pool element. Message Flow elements are not to be confused with Sequence Flow elements.

Use Message Flow elements to represent collaboration and transfer of Request data from one Pool to another. Since each Pool element in a Process uses its own Request and Request data, use Message Flow elements to exchange data and information between separate Pool elements and/or elements within those Pool elements.

These messages indicate the transfer of Request data between separate Process model elements. Use a Text Annotation element to add descriptive information about the nature of the data transfer.

The Flow indicator displays when you click an element or connector in the Process model. ProcessMaker Platform knows whether to use an outgoing Sequence Flow or Message Flow element depending on the selected element or connector selected and its context within the Process model.

Flow indicator (highlighted) on a selected Process element

These messages indicate the transfer of Request data between separate Process model elements. Use a Text Annotation element to add descriptive information about the nature of the data transfer.

A Message Flow element (dotted line) between two elements in different Pool elements

The following BPMN 2.0 elements do not use outgoing Message Flow elements:

See Connect Message Flow Elements to Indicate Collaboration.

Related articles