Manage and Model Processes
ProcessMaker API Documentation
Script Central

Process Modeling Element Descriptions

These are brief descriptions about commonly used Process modeling elements.

Overview

The following are brief descriptions about each Process modeling element that ProcessMaker provides. See the BPMN 2.0 specification for more information.

Looking for Information About Connectors?

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

Permissions Required

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

  • Processes: View Processes

  • Processes: Edit Processes

See the Process permissions or ask your ProcessMaker Administrator for assistance.

Events

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

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

Start Event

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

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

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

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

  • The Request can be started via the ProcessMaker API.

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

Start Event element

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

Message Start Event

A Message Start Event element starts a Request for a Process when it triggers from a 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.

This message may originate from any of the following:

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

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

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

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

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

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

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

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

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

Message Start Event

Intermediate Timer Event

An Intermediate Timer Event element delays 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 Process's Request. Use this element to cause a Request to wait until a specific time. For example, use this element to make a Process wait 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 Message Catch Event

An Intermediate Message Catch Event element delays a Request until that element receives a 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.

This 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. Use this functionality to resume workflow to the Process Request using the Intermediate Message Catch Event element from another Request. If the Intermediate Message Catch Event element is in the same Process model as the Intermediate Message Throw Event element for which it listens for its message, these elements must be in separate Pool elements since each Pool element has its own Request.

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

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

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

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

  1. Workflow in the Request using the Intermediate Message Catch Event element pauses when it reaches this event. The Intermediate Message Catch Event element 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 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 message is ignored.

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.

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" Task element.

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

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

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

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

Intermediate Message Catch Event element

Intermediate Message Throw Event

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

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

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

  1. The Intermediate Message Throw Event element triggers.

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

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

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

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

Intermediate Message Throw Event element

End Event

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

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

End Event element

Message End Event

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

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

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

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

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

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

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

Message End Event element

Error End Event

An Error End Event element records the error before that Request completes if an error occurs. The purpose of sending the error is to provide an alternate business solution if expected workflow routing experiences 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

Boundary Timer Event

A Boundary Timer Event element represents alternate workflow routing when a specified amount of time expires with a Task element, Script Task element, Manual Task element, or Sub Process element. Workflow routes through the Boundary Timer Event element when the specified time expires. Use a Boundary Timer Event element to design business solutions when intended or best-case workflow in your Process does not occur in an expected period of time. Consider these examples:

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

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

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

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

An element associated with a Boundary Timer Event may also associate with a Boundary Error Event and/or a Boundary Message Event in the same element.

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

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

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

Below is a Boundary Timer Event element when it is associated with a Task element. A Boundary Timer Event may also be associated with a Script Task element, Manual Task element, or Sub Process element.

Boundary Timer Event element associated with a Task element

Boundary Error Event

A Boundary Error Event element represents alternate workflow routing when an error occurs with a Task element, Script Task element, Manual Task element, or Sub Process element. Workflow routes through the Boundary Error Event element when its associated element errors or, in the case with a Sub Process element, receives an error from its child Request. Use a Boundary Error Event element to design business solutions when intended or best-case workflow in your Process does not occur because of an error. Consider these examples:

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

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

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

An element associated with a Boundary Error Event may also associate with a Boundary Timer Event and/or a Boundary Message Event in the same element.

Below is a Boundary Error Event element when it is associated with a Script Task element. A Boundary Error Event may also be associated with a Task element, Manual Task element, or Sub Process element.

Boundary Error Event element associated with a Script Task element

Boundary Message Event

A Boundary Message Event element represents alternate workflow routing from a Sub Process element when that Boundary Message Event element receives a message from an Intermediate Message Throw Event element or a Message End Event element in the child Request. Use a Boundary Message Event element to design business solutions for different outcomes in the child Request.

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

A Sub Process element associated with a Boundary Message Event may also associate with a Boundary Timer Event and/or a Boundary Error Event in the same element.

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

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

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

Below is a Boundary Message Event element associated with a Sub Process element.

Boundary Message Event element associated with a Sub Process element

Tasks

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

Task

A Task element represents an activity a person performs while participating in a Request via ProcessMaker. A 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 Task element represents to any of the following types of Request participants:

  • The ProcessMaker user who started the Request, referred to as the Requester

  • A specific ProcessMaker user

  • Any member of a specified ProcessMaker group

  • The previous Task assignee in that Request's workflow

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

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

Task element

Script Task

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

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

  • Connect with third-party services like Adobe DocuSign, Short Message Service (SMS), or APIs.

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

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

Script Task element

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 Task element, in which a person performs an activity via ProcessMaker. 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

Sub Process

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

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

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

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

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

Sub Process element

Gateways

Gateway elements route Request workflow in the following ways:

Exclusive Gateway

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

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

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

Exclusive Gateway element

See the following topics about Exclusive Gateway elements:

Inclusive Gateway

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

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

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

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

Use two Inclusive Gateway elements for both converging and diverging workflow

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

Inclusive Gateway element

Parallel Gateway

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

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

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

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

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

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

Parallel Gateway element

Event-Based Gateway

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

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

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

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

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

Event-Based Gateway element example

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

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

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

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

Event-Based Gateway element

Organize Process Participants

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

Pool

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

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

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

Pool element containing a modeled Process

Lane

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

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

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

Text Annotations and Associations

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

Text Annotation

A Text Annotation element is human-readable text in a Process model that provides description about the Process. Text Annotation elements perform no functional role in Process Requests or workflow routing.

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

Text Annotation element

Association

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

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

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

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

Flow Indicators

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

Sequence Flow

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

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

In Process Modeler, Flow indicators display when you click an element in the Process model. The top Flow indicator is for Sequence Flows (highlighted below), represented with a solid line.

Sequence Flow indicator (highlighted) on a selected Process model element

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

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

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

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

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

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

Message Flow

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

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

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

Message Flow indicator (highlighted) on a selected Process element

These messages indicate indirect communication between separate Process participants. The Message Flow element does not indicate whether the message is physical or digital. Use a Text Annotation element to add information about the type of communication.

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

Related Topics