These are brief descriptions about commonly used Process modeling elements.
The following are brief descriptions about each Process modeling element that ProcessMaker Platform provides. See the BPMN 2.0 specification for more information.
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:
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.
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
Manual Task element
Script Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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 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. Note that this feature is only available if the Web Entry package is installed. See Web Entry.
The Request can be started via our RESTful API.
Below is a Start Event element when it has been placed into a Process model.
Below is a Start Event element configured to use Web Entry.
See how to add and configure Start Event elements.
Below is a Start Timer Event element when it has been placed into a Process model.
See how to add and configure Start Timer Event elements.
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:
Signal Start Event elements function as follows during a Request:
All Signal Start Event elements listen for a specified broadcasting Signal.
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.
That triggering element broadcasts its Signal containing Request data.
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.
Processes that use Signal Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Signal Start Event elements.
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.
The message may originate from any of the following:
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:
The Message Start Event element listens for a message based on that message's name. The message name is a placeholder for the message.
The Intermediate Message Throw Event element or Message End Event element triggers.
That triggering element sends its message containing Request data to the Message Start Event element.
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.
Processes that use Message Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Message Start Event elements.
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.
Below is a Conditional Start Event element when it has been placed into a Process model.
Processes that use Conditional Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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.
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:
Each Intermediate Signal Catch Event element functions as follows during its Request:
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.
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.
That triggering element broadcasts its Signal containing Request data.
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.
Processes that use Intermediate Signal Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
The purpose of the broadcasting Signal may be the following:
An Intermediate Signal Throw Event element functions as follows during a Request:
The Intermediate Signal Throw Event element triggers.
The Intermediate Signal Throw Event element broadcasts its specified Signal.
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.
Processes that use Intermediate Signal Throw Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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:
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.
An Intermediate Message Catch Event element functions as follows during a Request:
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.
The Intermediate Message Throw Event element or Message End Event element triggers.
That triggering element sends its message containing Request data to the Intermediate Message Catch Event element.
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.
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:
Workflow delays after the "Preparation" Form Task element.
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.
In the "Purchase Fulfillment" Request, the Intermediate Message Catch Event element triggers and receives the Intermediate Message Throw Event element's message.
Workflow resumes in the "Purchase Fulfillment" Request.
Below is an Intermediate Message Catch Event element when it has been placed into a Process model.
Processes that use Intermediate Message Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
An Intermediate Message Throw Event element functions as follows during a Request:
The Intermediate Message Throw Event element triggers.
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.
If the message name matches that for which the catching element is listening, then that element triggers. Otherwise, the message is ignored.
Below is an Intermediate Message Throw Event element when it has been placed into a Process model.
Processes that use Intermediate Message Throw Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Below is an Intermediate Conditional Catch Event element when it has been placed into a Process model.
Processes that use Intermediate Conditional Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Below is an End Event element when it has been placed into a Process model.
See how to add and configure End Event elements.
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.
Processes that use Message End Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Message End Event elements.
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 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 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.
See how to add and configure Error End Event elements.
The purpose of the broadcasting Signal may be the following:
A Signal End Event element functions as follows during a Request:
The Signal End Event element triggers, thereby completing its Request.
The Signal End Event element broadcasts its specified Signal.
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.
Processes that use Signal End Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Signal End Event elements.
Consider the following Process as an example to distinguish between an End Event element and a Terminate End Event element.
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.
See how to add and configure Terminate End Event elements.
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:
Script Task element
Manual Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
DocuSign connector (requires the DocuSign package)
IDP connector (requires the IDP package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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.
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 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:
Configure whether a Boundary Timer Event element interrupts the best-case scenario workflow:
Processes that use Boundary Timer Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Boundary Timer Event elements.
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:
Script Task element
Manual Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
DocuSign connector (requires the DocuSign package)
IDP connector (requires the IDP package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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.
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 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.
An element or connector associated with a Boundary Error Event element may also associate with the following elements in the same element/connector:
Below is a Boundary Error Event element when it is associates with a Script Task element.
Processes that use Boundary Error Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Boundary Error Event elements.
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:
Script Task element
Manual Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
DocuSign connector (requires the DocuSign package)
IDP connector (requires the IDP package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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.
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 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:
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:
Configure whether a Boundary Signal Event element interrupts the best-case scenario workflow:
Processes that use Boundary Signal Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Boundary Signal Event elements.
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:
Script Task element
Manual Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
DocuSign connector (requires the DocuSign package)
IDP connector (requires the IDP package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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.
During an in-progress Request, the Boundary Message Event element may trigger in the following circumstances:
The Boundary Message Event element associates with an element or connector.
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.
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 a Boundary Message Event element to design business solutions that adjust workflow routing from the best-case scenario. Consider these examples:
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:
Processes that use Boundary Message Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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:
Script Task element
Manual Task element
Sub Process element
Actions By Email connector (requires the Actions By Email package)
Data Connector connector (requires the Data Connector package)
DocuSign connector (requires the DocuSign package)
IDP connector (requires the IDP package)
PDF Generator connector (requires the PDF Generator package)
Send Email connector (requires the Send Email package)
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.
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 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:
Configure whether a Boundary Conditional Event element interrupts the workflow when this element's specified Request conditions are met:
Processes that use Boundary Conditional Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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:
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.
See how to add and configure Form Task elements.
Below is a Manual Task element when it has been placed into a Process model.
See how to add and configure Manual Task elements.
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
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.
See how to add and configure Script Task elements.
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.
Below is a Sub Process element when it has been placed into a Process model.
See how to add and configure Sub Process elements.
Gateway elements route Request workflow in the following ways:
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.
Processes that use Exclusive Gateway elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See the following topics about Exclusive Gateway elements:
An Inclusive Gateway element functions in two different ways, but not at the same time from the same element:
One Inclusive Gateway element can only converge or diverge workflow, but not both. Use two Inclusive Gateway elements to both converge and diverge workflow.
Below is an Inclusive Gateway element when it has been placed into a Process model.
Processes that use Inclusive Gateway elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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.
Below is a Parallel Gateway element when it has been placed into a Process model.
Processes that use Parallel Gateway elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Parallel Gateway elements.
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:
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.
In this example, connect the following Process modeling elements from the Event-Based Gateway element:
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.
Processes that use Event-Based Gateway elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Event-Based Gateway elements.
BPMN 2.0 provides graphical representations to organize participants and roles in a Process model.
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.
Processes that use multiple Pool elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
See how to add and configure Pool elements.
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.
See how to add and configure Lane elements.
ProcessMaker Platform provides the following Process model elements that are for visual representation only:
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.
See how to add and configure Text Annotation elements.
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.
See how to add and configure Association elements.
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.
See how to add and configure Data Object elements.
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.
See how to add and configure Data Store elements.
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.
See how to add and configure Data Association Flow elements.
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:
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.
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.
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.
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.
The following BPMN 2.0 elements do not use outgoing Message Flow elements:
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.
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.
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.
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.