ProcessMaker Documentation
Search…
ProcessMaker 4.2
Use ProcessMaker
JSON: The Foundation of Request Data
Manage and Model Processes
ProcessMaker Administration
Download for On-Premises Installation
ProcessMaker API Documentation
ProcessMaker Examples
Deprecation Notices
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 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
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 our API. A Start Event element cannot have an incoming Sequence Flow element, though it may have an outgoing Message Flow element. A Process model can have multiple Start Event elements, each representing a different user or group (or via Web entry if the Web Entry package is installed).
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.
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 receives a specific broadcasting Signal designed in Signal Manager 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 to receive the broadcast. Pool elements within the same Process model that contain Signal Start Event elements also trigger.
The Signal Start Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when starting a Request.
The broadcasting Signal may originate from any of the following:
- Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a Signal that contains none, part, or all of its current Request data to all Signal Start Event elements in all Processes listening for that Signal. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The Signal Start Event element references the Signal's payload when starting the new Request. Use this functionality to start different Requests simultaneously while the Request that broadcasts the Signal is in progress.
- Signal End Event element: A Signal End Event element broadcasts a Signal that contains none, part, or all of its Request data to all Signal Start Event elements in all Processes listening for that Signal. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The Signal Start Event element references the Signal's payload when starting the new Request. Use this functionality to start a different Request when the Request that broadcasts the Signal completes.
Signal Start Event elements function as follows during a Request:
- 1.All Signal Start Event elements listen for a specified broadcasting Signal.
- 2.The Intermediate Signal Throw Event element or Signal End Event element triggers from a separate Request not necessarily represented in the same Process model as any Signal Start Event element.
- 3.That triggering element broadcasts its Signal containing Request data.
- 4.For each Signal Start Event element in any Process, if the Signal ID matches that for which it is listening for its broadcast, then that Signal Start Event element triggers, thereby starting a Request for its Process. Otherwise, the Signal is ignored for those Signal Start Event elements not listening for that Signal and those Processes do not start a Request.
Below is a Signal Start Event element when it has been placed into a Process model.
Signal Start Event element
Processes that use Signal Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Message Start Event
A Message Start Event element starts a Request for a Process when it triggers from a specific message. The Message Start Event element listens for a message from a specified source. The purpose of the message transfer is to send data from one Pool element's Request data to another Pool element within the same Process model, thereby using the sent Request data to start a Request for the receiving Pool element; each Pool element represents its own Request with its own distinct Request data.
A Message Flow element can connect from the element sending the message to the Message Start Event element. A Process model can have multiple Message Start Event elements.
The message may originate from any of the following:
- Intermediate Message Throw Event element: An Intermediate Message Throw Event element sends a message to the Message Start Event. Use this functionality to start a different Process's Request while the Request that sends the message is in progress. If the Message Start Event element is in the same Process model as the Intermediate Message Throw Event element for which it listens for its message, these elements must be in separate Pool elements since each Pool element has its own Request.
- Message End Event element: A Message End Event element sends a message to the Message Start Event. Use this functionality to start a different Process's Request when the Request that sends the message completes. If the Message Start Event element is in the same Process model as the Message End Event element for which it listens for its message, these elements must be in separate Pool elements.
- Third-party service: A third-party service such as a CRM may send a message via our API to the Message Start Event, thereby starting a Request.
A Message Start Event element functions as follows during a Request:
- 1.The Message Start Event element listens for a message based on that message's name. The message name is a placeholder for the message.
- 2.The Intermediate Message Throw Event element or Message End Event element triggers.
- 3.That triggering element sends its message containing Request data to the Message Start Event element.
- 4.If the message name matches that for which the Message Start Event element is listening, then that element triggers, thereby starting the Request. Otherwise, the message is ignored.
Below is a Message Start Event element when it has been placed into a Process model.
Message Start Event element
Processes that use Message Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Conditional Start Event
A Conditional Start Event element starts a Request for a Process when that element's condition(s) are met to do so. The Conditional Start Event element's condition(s) can pertain to a Request's data in any Process. The Conditional Start Event element triggers when its specified conditions are met; until its conditions are met, that Conditional Start Event element does not trigger and therefore does not start a Request. Use this element to conditionally start a Request from any other Request.
A Process may use multiple Conditional Start Event elements. However, each Conditional Start Event element must use a unique condition for that element to trigger unless each Conditional Start Event element is in a separate Pool element.
Below is a Conditional Start Event element when it has been placed into a Process model.
Conditional Start Event element
Processes that use Conditional Start Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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 broadcasting Signal designed in Signal Manager from a broadcasting element in any other Request. These paused Requests may be for many different Process models. The element that broadcasts the Signal does not need to be in the same Process model as the Intermediate Signal Catch Event element to receive the broadcast. Pool elements within the same Process model that contain Intermediate Signal Catch Event elements also trigger.
The Intermediate Signal Catch Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when resuming its Request.
The broadcasting Signal may originate from any of the following:
- Intermediate Signal Throw Event element: An Intermediate Signal Throw Event element broadcasts a specified Signal containing none, part, or all of its Request data to all Intermediate Signal Catch Event elements in paused Requests while the Intermediate Signal Catch Event element(s) in those Requests listens for that Signal. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The Intermediate Signal Catch Event element references the Signal's payload when resuming its Request. Use this functionality to resume workflow for potentially multiple paused Requests as soon as the Intermediate Signal Throw Event broadcasts the Signal.
- Signal End Event element: A Signal End Event element broadcasts a specified Signal containing none, part, or all of its Request data to all Intermediate Signal Catch Event elements in paused Requests while the Intermediate Signal Catch Event element(s) in those Requests listens for that Signal. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The Intermediate Signal Catch Event element references the Signal's payload when resuming its Request. Use this functionality to resume workflow for potentially multiple paused Requests as soon as the Signal End Event element completes its Request.
Each Intermediate Signal Catch Event element functions as follows during its Request:
- 1.Workflow in each Request using an Intermediate Signal Catch Event element pauses when it reaches this event. Each Intermediate Signal Catch Event element waits for a specified broadcasting Signal.
- 2.The Intermediate Signal Throw Event element or Signal End Event element triggers from a separate Request not necessarily represented in the same Process model as any Intermediate Signal Catch Event element.
- 3.That triggering element broadcasts its Signal containing Request data.
- 4.Each Intermediate Signal Catch Event element in each paused Request that matches the broadcasting Signal triggers, thereby resuming workflow simultaneously in those Requests. Otherwise, that broadcasting Signal is ignored for those Intermediate Signal Catch Event elements not listening for that Signal and those Requests remain paused.
Below is an Intermediate Signal Catch Event element when it has been placed into a Process model.
Intermediate Signal Catch Event element
Processes that use Intermediate Signal Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Intermediate Signal Throw Event
An Intermediate Signal Throw Event element broadcasts a specific Signal designed in Signal Manager that contains none, part, or all of its current Request data when it triggers to all elements throughout that ProcessMaker instance. Any element listening for that specific Signal thereby triggers. In the Signal's payload, the Intermediate Signal Throw Event element may broadcast the entirety of the current Request data to that point in the Request's workflow, the current value of a Request variable, or specific Request data based on an expression. The element that listens for that broadcasting Signal does not need to be in the same Process model as the Intermediate Signal Throw Event element. Pool elements in the same Process model that contain elements listening for that Signal also trigger.
The purpose of the broadcasting Signal may be the following:
- Signal Start Event element: Broadcast a specific Signal to all Signal Start Event elements listening for that Signal to simultaneously start Requests for those Processes. The Signal Start Event element references the Signal's payload when starting the new Request.
- Intermediate Signal Catch Event element: Broadcast a specific Signal to all Intermediate Signal Catch Event elements listening for that Signal to simultaneously resume workflow for those Requests that have been paused. Each triggered Intermediate Signal Catch Event element references the Signal's payload when resuming its Request.
- Boundary Signal Event: Broadcast a specific Signal to all Boundary Signal Event elements listening for that Signal to follow alternative workflow from its associating element or connector. Each triggered Boundary Signal Event element references the Signal's payload when taking alternative workflow in its Request.
An Intermediate Signal Throw Event element functions as follows during a Request:
- 1.The Intermediate Signal Throw Event element triggers.
- 2.The Intermediate Signal Throw Event element broadcasts its specified Signal.
- 3.If the element is listening for that broadcasted Signal, then that listening element triggers. Otherwise, the Signal is ignored.
Below is an Intermediate Signal Throw Event element when it has been placed into a Process model.
Intermediate Signal Throw Event element
Processes that use Intermediate Signal Throw Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Intermediate Message Catch Event
An Intermediate Message Catch Event element pauses a Request until that element receives a specific message. The purpose of the message transfer is to send data between Requests running from the same Process model since each Pool element represents its own Request with its own distinct Request data.
The message may originate from any of the following:
- Intermediate Message Throw Event element: An Intermediate Message Throw Event element sends a message to the Intermediate Message Catch Event element that has paused its in-progress Request until the Intermediate Message Catch Event element receives its message. Use this functionality to resume workflow to the Request using the Intermediate Message Catch Event element from another Request. If the Intermediate Message Catch Event element is in the same Process model as the Intermediate Message Throw Event element for which it listens for its message, these elements must be in separate Pool elements since each Pool element has its own Request.
- Message End Event element: A Message End Event element sends a message to the Intermediate Message Catch Event. Use this functionality to resume workflow to the Process Request using the Intermediate Message Catch Event element when the Request that sends the message completes. If the Intermediate Message Catch Event element is in the same Process model as the Message End Event element for which it listens for its message, these elements must be in separate Pool elements.
- Third-party service: A third-party service such as a CRM may send a message via our API to the Intermediate Message Catch Event, thereby resuming workflow for that Request.
A Message Flow element can connect from the element sending the message to the Intermediate Message Catch Event element. Ensure that Intermediate Message Catch Event element and its triggering element are in different Pool elements. When configuring the Intermediate Message Catch Event element during Process modeling, select which message from the triggering element sends to the Intermediate Message Catch Event element.
An Intermediate Message Catch Event element functions as follows during a Request:
- 1.Workflow in the Request using the Intermediate Message Catch Event element pauses when it reaches this event. The Intermediate Message Catch Event element waits for a message based on that message's name. The message name is a placeholder for the message.
- 2.The Intermediate Message Throw Event element or Message End Event element triggers.
- 3.That triggering element sends its message containing Request data to the Intermediate Message Catch Event element.
- 4.If the message name matches that for which the Intermediate Message Catch Event element is listening, then that element triggers; workflow resumes in that Request. Otherwise, the Intermediate Message Catch Event element ignores the message.
Consider the following example how the Intermediate Message Catch Event element functions. This example uses the Intermediate Message Throw Event element in an overly simple purchase request and order fulfillment Process model. The Process model contains two Processes, each within its own Pool element. Each Process may potentially run its own Request.
Simple Process model example to demonstrate how an Intermediate Message Catch Event functions
The Intermediate Message Catch Event element (labeled "Catch from Order") is in the second Pool, "Purchase Fulfillment."
After the "Purchase Fulfillment" Request starts, the following occurs:
- 1.Workflow delays after the "Preparation" Form Task element.
- 2.When the Intermediate Message Throw Event element triggers from the "Purchase Order" Request (labeled "Throw to Fulfillment"), it sends its message to the Intermediate Message Catch Event element in the "Purchase Fulfillment" Request. Workflow continues in the "Purchase Order" Request to the End Event element.
- 3.In the "Purchase Fulfillment" Request, the Intermediate Message Catch Event element triggers and receives the Intermediate Message Throw Event element's message.
- 4.Workflow resumes in the "Purchase Fulfillment" Request.
Below is an Intermediate Message Catch Event element when it has been placed into a Process model.
Intermediate Message Catch Event element
Processes that use Intermediate Message Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Intermediate Message Throw Event
An Intermediate Message Throw Event element sends a message to a Message Start Event or an Intermediate Message Catch Event element. The purpose of the message transfer is to send data between Requests running from the same Process model since each Pool element represents its own Request with its own distinct Request data.
A Message Flow element can connect from the Intermediate Message Throw Event element to the element listening for its message.
An Intermediate Message Throw Event element functions as follows during a Request:
- 1.The Intermediate Message Throw Event element triggers.
- 2.The Intermediate Message Throw Event element sends its message. The message has a name which is a placeholder for the Request data it sends to the catching element.
- 3.If the message name matches that for which the catching element is listening, then that element triggers. Otherwise, the message is ignored.
See the Intermediate Message Catch Event element description for a simple example how an Intermediate Message Throw Event element works.
Below is an Intermediate Message Throw Event element when it has been placed into a Process model.
Intermediate Message Throw Event element
Processes that use Intermediate Message Throw Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Intermediate Conditional Catch Event
An Intermediate Conditional Catch Event element pauses a Request until specified conditions in that Request are met. An Intermediate Conditional Catch Event element only triggers when the specified condition(s) in that Request are met, thereby allowing workflow to route through its outgoing Sequence Flow element(s). Otherwise, that Request remains paused indefinitely unless the Process model provides an alternative for workflow routing. Use an Intermediate Conditional Catch Event element to design workflow routing to occur only when specific business conditions occur.
Below is an Intermediate Conditional Catch Event element when it has been placed into a Process model.
Intermediate Conditional Catch Event element
Processes that use Intermediate Conditional Catch Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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
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.
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 designed in Signal Manager that contains none, part, or all of its Request data when it triggers to all elements throughout that ProcessMaker instance. Any element listening for that specific Signal thereby triggers. The Signal End Event element triggers when its Request completes. In the Signal's payload, the Signal End Event element may broadcast the entirety of the Request data, the current value of a Request variable, or specific Request data based on an expression. The element that listens for that broadcasting Signal does not need to be in the same Process model as the Signal End Event element. Pool elements in the same Process model that contain elements listening for that Signal also trigger.
The purpose of the broadcasting Signal may be the following:
- Signal Start Event element: Broadcast a specific Signal to all Signal Start Event elements listening for that Signal to simultaneously start Requests for those Processes. The Signal Start Event element references the Signal's payload when starting the new Request.
- Intermediate Signal Catch Event element: Broadcast a specific Signal to all Intermediate Signal Catch Event elements listening for that Signal to simultaneously resume workflow for those Requests that have been paused. Each triggered Intermediate Signal Catch Event element references the Signal's payload when resuming its Request.
- Boundary Signal Event: Broadcast a specific Signal to all Boundary Signal Event elements listening for that Signal to follow alternative workflow from its associating element or connector. Each triggered Boundary Signal Event element references the Signal's payload when taking alternative workflow in its Request.
A Signal End Event element functions as follows during a Request:
- 1.The Signal End Event element triggers, thereby completing its Request.
- 2.The Signal End Event element broadcasts its specified Signal.
- 3.If the element is listening for that broadcasted Signal, then that listening element triggers. Otherwise, the Signal is ignored.
Below is a Signal End Event element when it has been placed into a Process model.
Signal End Event element
Processes that use Signal End Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
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 from the moment its associating element or connector triggers. The Boundary Timer Event element may associate with any of the following elements and connectors:
The Boundary Timer Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Timer Event element associates with a Form Task element.
Boundary Timer Event element associates with a Form Task element
During an in-progress Request, if the element/connector to which the Boundary Timer Event associates has triggered but is not yet complete and the specified time expires for which the Boundary Timer Event element is set, then workflow routes through the Boundary Timer Event element.
After the associating element/connector triggers, the Boundary Timer Event element starts the set timer but does not trigger. The Boundary Timer Event element triggers only after the set time expires and its associating element has not completed.
Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Timer Event element if triggers.
Use a Boundary Timer Event element to design business solutions when intended or best-case workflow in your Request does not occur in an expected period of time. Consider these examples:
- Escalate Task problems: When a Task assignee does not complete a Task when it is due, escalate to that assignee's manager to ensure project tasks are completed on schedule.
- Script fail-safe: If a Script does not complete in a period of time, route workflow to a system administrator to investigate why the Script provided no response.
- Escalate child sub-process problems: If the Request for a child Sub Process does not complete in a required period of time, route workflow to a manager's Task in the parent Process's Request so that the child Request does not delay the parent Request.
An element or connector associated with a Boundary Timer Event element may also associate with the following elements in the same element/connector:
A Sub Process element associated with a Boundary Timer Event may also associate with a Boundary Message Event element.
Configure whether a Boundary Timer Event element interrupts the best-case scenario workflow:
- Interrupting workflow: When workflow routes through the Boundary Timer Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Timer Event element if the Manual Task element does not complete within 30 minutes.
- Non-interrupting workflow: Workflow routes both through the Boundary Timer Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Timer Event element if the Manual Task element does not complete within 30 minutes; however, workflow also routes through the best-case scenario when the Manual Task element completes.
Processes that use Boundary Timer Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Boundary Error Event
A Boundary Error Event element represents alternate workflow routing when an error occurs with its associating element or connector. The Boundary Error Event element may associate with any of the following elements and connectors:
The Boundary Error Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Error Event element associates with a Script Task element.
Boundary Error Event element associates with a Script Task element
During an in-progress Request, if the element/connector to which the Boundary Error Event associates has triggered but is not yet complete when any of the following occurs, then workflow routes through the Boundary Error Event element:
- An error occurs in the associating element/connector.
- The Boundary Error Event element associates with a Sub Process element and that element receives an error from its child Request.
If the element/connector to which the Boundary Error Event element associates has not triggered, then the Boundary Error Event element does not trigger when the error occurs. The Boundary Error Event element may only trigger if the error occurs in its associating element/connector.
Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Error Event element if it triggers.
Use a Boundary Error Event element to design business solutions when intended or best-case workflow does not occur because of a Request error. Consider these examples:
- Technical error with a Script: If a running Script returns an error, route workflow to a system administrator's Task to investigate why the Script failed.
- Escalate child sub-process problems: If the Error End Event element in a child Request captures a Request error, the Boundary Error Event element associated with the parent Request's Sub Process element receives the error, then routes workflow to a system administrator's Task in the parent Process's Request to investigate the issue in the child Request.
An element or connector associated with a Boundary Error Event element may also associate with the following elements in the same element/connector:
A Sub Process element associated with a Boundary Error Event may also associate with a Boundary Message Event element.
Below is a Boundary Error Event element when it is associates with a Script Task element.
Boundary Error Event element associates with a Script Task element
Processes that use Boundary Error Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Boundary Signal Event
A Boundary Signal Event element represents alternate workflow routing when that element receives a specific broadcasting Signal designed in Signal Manager. The Boundary Signal Event may associate with any of the following elements and connectors:
The Boundary Signal Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Signal Event element associates with a Form Task element.
Boundary Signal Event element associates with a Form Task element
During an in-progress Request, if the element/connector to which the Boundary Signal Event associates has triggered but is not yet complete and the Boundary Signal Event element receives the broadcasting Signal for which it listens, then workflow routes through the Boundary Signal Event element. The element that broadcasts the Signal does not need to be in the same Process model as the Boundary Signal Event element to receive the broadcast Signal. If the broadcasting Signal is in a different Pool element within the same Process model, the Boundary Signal Event also triggers.
The Boundary Signal Event element receives any Request data in the broadcasting Signal's payload. Request data in the Signal's payload may be referenced when routing its Request.
If the element/connector to which the Boundary Signal Event element associates has not triggered when the Signal broadcasts, then the Boundary Signal Event element does not trigger.
Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Signal Event element if it triggers.
Use a Boundary Signal Event element to design business solutions when alternate workflow must occur in multiple Requests, even if those Requests derive from separate Processes. Consider these examples:
- Escalate multiple Requests simultaneously to higher management: Use an Intermediate Signal Throw Event element to broadcast a specific signal to indicate that higher management needs to participate in multiple separate Requests simultaneously: when all Boundary Signal Event elements receive the specific Signal, workflow routes to alternate Task assignees to escalate a problem in each separate Request.
- Broadcast a Signal when a separate Request completes: When a separate Request completes, a Signal End Event element broadcasts a specific Signal that indicates that Request's completion. All Boundary Signal Event elements from all in-progress Requests trigger simultaneously to route through alternate workflow. This design may be a business solution to indicate work on multiple Requests may not be necessary and workflow may route to end each of those Requests simultaneously.
- Broadcast a Signal from a child sub-process: If during a Request for a child Sub Process broadcasts a Signal from an Intermediate Signal Throw Event or Signal End Event element, all Boundary Signal Event elements from all in-progress Requests trigger simultaneously to route through alternate workflow.
An element or connector associated with a Boundary Signal Event element may also associate with the following elements in the same element/connector:
A Sub Process element associated with a Boundary Signal Event may also associate with a Boundary Message Event element.
Configure whether a Boundary Signal Event element interrupts the best-case scenario workflow:
- Interrupting workflow: When workflow routes through the Boundary Signal Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Signal Event element if the Boundary Signal Event element receives the specific broadcasting Signal for which it is listening.
- Non-interrupting workflow: Workflow routes both through the Boundary Signal Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Signal Event element while the Form Task element is in progress; however, workflow also routes through the best-case scenario when the Form Task element completes.
Processes that use Boundary Signal Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Boundary Message Event
A Boundary Message Event element represents alternate workflow routing when its associating element or connector receives a specific message as designated by the message's name. The associating element/connector must have triggered at the moment it receives the message. The Boundary Message Event element may associate with any of the following elements or connectors:
The Boundary Message Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Message Event element associates with a Sub Process element.
Boundary Message Event element associates with a Sub Process element
During an in-progress Request, the Boundary Message Event element may trigger in the following circumstances:
- 1.The Boundary Message Event element associates with an element or connector.
- 2.The Boundary Message Event element receives a specified message, designated by the message's unique name, prior to the associating element/connector triggering or completing.
- 3.The Boundary Message Event element triggers. Either of the following may occur depending on if the Boundary Message Event element is configured to be "interrupting" or "non-interrupting":
- Interrupting: If the Boundary Message Event element is configured to be interrupting, its associating element/connector never triggers in that Request. Workflow routes through the Boundary Message Event element.
- Non-interrupting: If the Boundary Message Event element is configured to be non-interrupting, the associating element/connector may potentially trigger in that Request if workflow routes to it. However, the Boundary Message Event element triggers when it receives its message, which may be temporally a different time than when the associating element/connector may trigger. If the associating element/connector triggers and completes, workflow routes through it. Both workflows may possible occur.
Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Message Event element if it triggers.
Use a Boundary Message Event element to design business solutions that adjust workflow routing from the best-case scenario. Consider these examples:
- Boundary Message Event element receives message from another Pool element: Use an Intermediate Message Throw Event element that is in one Pool element to send a message to a Boundary Message Event element in a second Pool element. Each Pool element contains independent workflow: each is a separate Request. The Boundary Message Event element receives Request data from the Intermediate Message Throw Event element's Request. The Boundary Message Event element's Request resumes with Request data from the other Request.
- Two elements listen for different messages: Associate a Boundary Message Event element with an Intermediate Message Catch Event element. Each of these elements listen for a different message, thereby providing two workflow routing options from this junction in the Process model.
An element or connector associated with a Boundary Message Event element may also associate with the following elements in the same element/connector:
Configure whether a Boundary Message Event element interrupts the best-case scenario workflow:
- Interrupting workflow: When workflow routes through the Boundary Message Event element, workflow is interrupted and does not route through the best-case scenario. As highlighted in the example below, workflow routes through the Boundary Message Event element if that element receives a message from the child Request.
- Non-interrupting workflow: Workflow routes both through the Boundary Message Event element and the best-case scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Message Event element if that element receives a message from the child Request; however, after the child Request completes and workflow resumes in the parent Request, the Sub Process element completes and routes through the best-case scenario.
Processes that use Boundary Message Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Boundary Conditional Event
A Boundary Conditional Event element represents alternate workflow routing when the Boundary Conditional Event element evaluates specified Request conditions have occurred at the moment its associating element or connector triggers. The Boundary Conditional Event element may while associate with any of the following elements and connectors:
The Boundary Conditional Event element associates with an element or connector by attaching to it to that element or connector. Below a Boundary Conditional Event element associates with a Form Task element.
Boundary Conditional Event element associates with a Form Task element
During an in-progress Request, if the element/connector to which the Boundary Conditional Event associates has triggered but is not yet complete and the Boundary Conditional Event element's condition is met, then workflow routes through the Boundary Conditional Event element.
If the element/connector to which the Boundary Conditional Event element associates has not triggered, then the Boundary Conditional Event element does not trigger regardless of the Boundary Conditional Event element's conditions.
Use an outgoing Sequence Flow element to indicate workflow routing from the Boundary Conditional Event element if it triggers.
Use a Boundary Conditional Event element to design business solutions for nuanced business conditions in your business solution. Consider these examples:
- Evaluate if a purchase receipt is required: A PDF Generator connector can generate a PDF for a receipt in a purchase-related Process. Associate a Boundary Conditional Event element with the PDF Generator connector to evaluate if the connector generates a Screen of the receipt based on a Request variable value the purchasing agent has previously selected to indicate if a receipt is required.
- Evaluate if enrolled courses are valid prior to payment: A university student's Form Task element triggers to pay for course enrollments that semester. Associate that Form Task element with a Boundary Conditional Event element to evaluate if all enrolled courses are still valid at the time of payment: if any enrolled course offering or schedule has changed, route to a Send Email connector to send an email to that student notifying of course changes prior to payment.
An element or connector associated with a Boundary Conditional Event element may also associate with the following elements in the same element/connector:
A Sub Process element associated with a Boundary Conditional Event may also associate with a Boundary Message Event element.
Configure whether a Boundary Conditional Event element interrupts the workflow when this element's specified Request conditions are met:
- Interrupting workflow: When workflow routes through the Boundary Conditional Event element, workflow is interrupted and does not route through the default scenario route. As highlighted in the example below, workflow routes through the Boundary Conditional Event element if this element's specified Request conditions are met.
- Non-interrupting workflow: Workflow routes both through the Boundary Conditional Event element and the default scenario, thereby creating parallel workflow in that Request. As highlighted in the example below, workflow routes through the Boundary Conditional Event element if this element's specified Request conditions are met; however, workflow also routes through the default scenario when the Manual Task element completes.
Processes that use Boundary Conditional Event elements can be complex. Therefore, if the Process Optimization package is installed, use it to test workflow variations while designing such Processes.
Tasks
Tasks represent activities performed by persons in ProcessMaker software, offline (such as in the physical environment), or by a 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 user who started the Request, referred to as the Request starter.
- The previous Task assignee in that Request's workflow
People perform Task activities through Screens as digital forms and displays. Screens are designed in Screens Builder.
Below is a Form Task element when it has been placed into a Process model.
Form Task element
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 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 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 integrates with third-party services Amazon Textract and UiPath Robotic Process Automation (RPA) so a loan application workflow scans, analyzes, and intelligently routes a Request and provision a bot accordingly.
- Intended audience: Process designers and business analysts
- Viewing time: 11 minutes; contains narration
Script Tasks integrate with third-party services and RPAs in a Process demonstration
Scripts are designed in Script Editor. Scripts are independent of Process models: any Script can be reused in any Process model in your organization. This architecture allows Process Owners to focus on Process modeling in a no-code environment while ProcessMaker Developers develop reusable Scripts. Scripts can leverage Screens variable values for in-progress Requests.
Below is a Script Task element when it has been placed into a Process model.
Script Task element
Sub Process
A Sub Process element calls a Sub Process that can be re-used by other Processes. The Sub Process that the Sub Process element calls is referred to as the "child" Sub Process and must be an external Process from the calling Process it (referred to as the "parent" Process).
The child Sub Process 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
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.