Manage and Model Processes
ProcessMaker API Documentation
Script Central

Process Modeling Element Descriptions

These are brief descriptions about commonly used Process modeling elements.

Overview

The following are brief descriptions about each Process modeling element that ProcessMaker 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 integrates with that third-party service during Requests. See the following topics for more information:

Permissions Required

Your ProcessMaker 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 ProcessMaker Administrator for assistance.

Topic Updated

This topic is updated for ProcessMaker version 4.0.4. See the Release Notes.

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 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 the ProcessMaker 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 ProcessMaker user or group (or via Web entry if the Web Entry package is installed to your ProcessMaker instance).

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 ProcessMaker user (Jane Doe) or any member of a specified group (Accounting department).

  • The Request can be started by either an anonymous or authenticated ProcessMaker user through a published URL. This allows a ProcessMaker Screen to be available on a public-facing Web site that starts the Request when that Screen is submitted. Note that this feature is only available if the Web Entry package is installed in your ProcessMaker instance. See Web Entry.

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

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

Signal Start Event

A Signal Start Event element starts a Request for a Process when it triggers by receiving a specific broadcast signal from a broadcasting element in any other Request in that ProcessMaker instance. The element that broadcasts the signal does not need to be in the same Process model as the Signal Start Event element that receives the broadcast.

The signal may originate from any of the following:

  • Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a signal and its Request data to all Signal Start Event elements in all Processes listening for that signal. Use this functionality to start different Process Requests simultaneously while the Request that broadcasts the signal is in progress.

  • Signal End Event element: A Signal End Event element broadcasts a signal and its Request data to all Signal Start Event elements in all Processes listening for that signal. Use this functionality to start a different Process's 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 broadcast based on the signal name. The signal name is a placeholder for the broadcast.

  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 in that ProcessMaker instance, if the signal name 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

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 the ProcessMaker 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

Conditional Start Event

A Conditional Start Event element starts a child Request for a Process when a parent Request sends its Request data to the Conditional Start Event element via a Sub Process element. The Conditional Start Event element triggers when the parent Request's data meets one or more specified conditions; otherwise, the Conditional Start Event ignores the call to start a Request. Use this element to conditionally start a child Request from another Request.

A Process model may use multiple Conditional Start Event elements. However, each Conditional Start Event element must use a unique condition for that element to trigger.

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

Conditional Start Event element

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

Intermediate Signal Catch Event

An Intermediate Signal Catch Event element pauses a Request until that element receives a specific signal from a broadcasting element in any other Request in that ProcessMaker instance. 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 that receives the broadcast.

The signal may originate from any of the following:

  • Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a signal and its Request data to all Intermediate Signal Catch Event elements in all in-progress Requests that have paused while the Intermediate Signal Catch Event element(s) in those Requests listens for that signal. 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 signal and its Request data to all Intermediate Signal Catch Event elements in all in-progress Requests that have paused while the Intermediate Signal Catch Event element(s) in those Requests listens for that signal. 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 signal based on that signal's name. The signal name is a placeholder for the broadcast.

  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. For each Intermediate Signal Catch Event element in each paused Request that matches the broadcast signal name, that Intermediate Signal Catch Event element triggers, thereby resuming workflow simultaneously with all other Intermediate Signal Catch Event elements listening for the same signal name. Otherwise, the 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

Intermediate Signal Throw Event

An Intermediate Signal Throw Event element broadcasts a specific signal and its Request data when it triggers to all elements throughout that ProcessMaker instance listening for that signal. The element that listens for the broadcast signal does not need to be in the same Process model as the Intermediate Signal Throw Event element.

The purpose of the broadcast signal may be the following:

  • Signal Start Event element: Broadcast a named signal to all Signal Start Event elements to simultaneously start Requests for those Processes with a Signal Start Event element listening for that named signal. Reference Request data from the Intermediate Signal Throw Event element's Request when Signal Start Event elements start their Requests.

  • Intermediate Signal Catch Event element: Broadcast a named signal to all Intermediate Signal Catch Event elements to simultaneously resume workflow for those Requests that have been paused with an Intermediate Signal Catch Event element listening for that named signal. Reference Request data from the Intermediate Signal Throw Event element's Request when resuming the Intermediate Signal Catch Event element's 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 signal. The signal has a name which is a placeholder for the Request data it broadcasts to all listening elements.

  3. If the signal name matches that for which any element in that ProcessMaker instance is listening, 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

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 the ProcessMaker 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

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

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

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

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

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

Signal End Event

A Signal End Event element broadcasts a specific signal and its Request data when it triggers to all elements throughout that ProcessMaker instance listening for that signal. The Signal End Event element triggers when its Request completes. The element that listens for the broadcast signal does not need to be in the same Process model as the Signal End Event element.

The purpose of the broadcast signal may be the following:

  • Signal Start Event element: Broadcast a named signal to all Signal Start Event elements to simultaneously start Requests for those Processes with a Signal Start Event element listening for that named signal. Reference Request data from the Signal End Event element's Request when Signal Start Event elements start their Requests.

  • Intermediate Signal Catch Event element: Broadcast a named signal to all Intermediate Signal Catch Event elements to simultaneously resume workflow for those Requests that have been paused with an Intermediate Signal Catch Event element listening for that named signal. Reference Request data from the Signal End Event element's Request when resuming the Intermediate Signal Catch Event element's 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 signal. The signal has a name which is a placeholder for the Request data it broadcasts to all listening elements.

  3. If the signal name matches that for which any element in that ProcessMaker instance is listening, then that listening element triggers. Otherwise, the signal is ignored.

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

Signal End Event element

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.

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

Terminate End Event element

Boundary Timer Event

A Boundary Timer Event element represents alternate workflow routing when a specified amount of time expires while associated 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 a Boundary Timer Event element to design business solutions when intended or best-case workflow in your Process 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.

  • ProcessMaker Script fail-safe: If a ProcessMaker 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.

Use a Sequence Flow element to indicate workflow routing if the Boundary Timer Event element triggers: when the configured timer expires before the associating element completes.

An element associated with a Boundary Timer Event element may also associate with the following elements in the same 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.

Boundary Error Event

A Boundary Error Event element represents alternate workflow routing when an error occurs while associated 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 and one 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 when the error occurs, then the Boundary Error Event element does not trigger.

Use a Sequence Flow element to indicate workflow routing if the Boundary Error Event element triggers: when this element receives an error before the associating element completes.

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

  • Technical error with a ProcessMaker Script: If a running ProcessMaker 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 associated with a Boundary Error Event element may also associate with the following elements in the same 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

Boundary Signal Event

A Boundary Signal Event element represents alternate workflow routing when that element receives a specific broadcast signal while associated 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 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 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 a Boundary Signal Event element to design business solutions when alternate workflow must occur in multiple Process Requests when a separate element in a separate Request broadcasts a signal for which any or all Boundary Signal Event elements is listening. 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 alternatively routes to different Task assignee 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 alternatively 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.

Use a Sequence Flow element to indicate workflow routing if the Boundary Signal Event element triggers: when the Boundary Signal Event element receives its signal before the associating element completes.

An element associated with a Boundary Signal Event element may also associate with the following elements in the same 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 broadcast signal for which it is listening if the Form Task element is not complete when receiving that signal.

  • 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 if the Form Task element is not yet complete; however, workflow also routes through the best-case scenario when the Form Task element completes.

Boundary Message Event

A Boundary Message Event element represents alternate workflow routing while associated with the following element or connector when that Boundary Message Event element receives a specific message:

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, if the element/connector to which the Boundary Message Event associates has triggered but is not yet complete and that associating element receives a specific message, then workflow routes through the Boundary Message Event element.

If the element/connector to which the Boundary Message Event element associates has not triggered when the message sends to that associating element, then the Boundary Message Event element does not trigger.

Use a Sequence Flow element to indicate workflow routing if the Boundary Message Event element triggers: when this element receives a message from the child Request.

Use a Boundary Message Event element to design business solutions for different outcomes in the child Request.

A Sub Process element associated with a Boundary Message Event element may also associate with the following elements in the same element:

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.

Boundary Conditional Event

A Boundary Conditional Event element represents alternate workflow routing when one or more specified Request conditions occur while associated 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 or has already completed, then the Boundary Conditional Event element does not trigger regardless of Request conditions.

Use a Sequence Flow element to indicate workflow routing if the Boundary Conditional Event element triggers.

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

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 and the Manual Task element has not yet completed.

  • 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.

Tasks

Tasks represent activities performed by persons in ProcessMaker software, offline (such as in the physical environment), or by a ProcessMaker Script. ProcessMaker 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. 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 ProcessMaker user who started the Request, referred to as the Requester

  • A specific ProcessMaker user

  • Any member of a specified ProcessMaker group

  • The previous Task assignee in that Request's workflow

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

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

Form Task element

Manual Task

A Manual Task element represents an activity a person performs offline and/or in the physical environment such that ProcessMaker cannot monitor its activity. A Manual Task element is different than a Form Task element, in which a person performs an activity via a ProcessMaker Screen. ProcessMaker 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 interaction.

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

Manual Task element

Script Task

A Script Task element represents an activity performed by a ProcessMaker Script. Use ProcessMaker 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 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

ProcessMaker Scripts are designed in Scripts Editor. ProcessMaker Scripts are independent of Process models: any ProcessMaker 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 ProcessMaker Scripts. ProcessMaker Scripts can leverage ProcessMaker 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

Sub Process

A Sub Process element calls a Sub Process that can be re-used by other Processes in the ProcessMaker instance. 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 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

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

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

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

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 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

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

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

Text Annotations and Associations

Use Text Annotation and Association elements to add human-readable descriptions about the Process model.

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.

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

Text Annotation element

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

Flow Indicators

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

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.

In Process Modeler, Flow indicators display when you click an element in the Process model. The solid-line Flow indicator is for Sequence Flow elements (highlighted below).

Sequence 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

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 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.

In Process Modeler, Flow indicators display when you click an element in the Process model. The dotted-line Flow indicator is for Message Flow elements (highlighted below).

Message 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

Related Topics