Contents: [hide]

Overview

An event is something that "occurs" during the course of a process. These events have a cause or an impact on the implementation of a process and usually require or permit an action.

Inside the Process Map of ProcessMaker, it is possible to find Start Events, Intermediate Events and End Events. Though most of them are currently available in the graphical process designer, only the following events are supported by the ProcessMaker engine:

Start Events

Intermediate Events

Throwing Events Catching Events

End Events

Inside the Process Map, the event shapes are in the shapes toolbox at the top side of the map.

The first two shapes among the event shapes of the toolbox are the start events: "Start Event" and "Start Timer Event". The next two shapes are the intermediate events: "Intermediate Email Event" (that represents the throwing events in the toolbar) and "Intermediate Timer Event" (that represents the catching events). The last two shapes are the "End Event" and "End Message Event".

Working with Events

Events are used inside the design of a process to indicate that something will happen at some point during the execution of the process. Thus, take into account the following:

  • Use Start Events to start a process.
  • Use Intermediate Events to indicate that something happens between the start of a process and the end of the process.
  • Use End Events to terminate the flow of a process.

Adding an Event to the Process Map

All the event shapes available in the shapes toolbox of the Process Map have the "Drag and Drop" property. This means that to add them to the Process Map they must simply be dragged from the shapes toolbox, taken to the map without releasing the mouse button and dropped on it.

For example, to add a start event:

Step 1 Step 2 Step 3

From version 3.0.1 and higher, use the "Quick Toolbar" option to easily add elements in the Process Map. This option gives the ability to add "throwing" intermediate events and/or end events from activities such as tasks and sub-processes, gateways and other events. To add a "catching" intermediate event drag the Timer Event from the shapes toolbox and drop it in the Process Map, change the type of intermediate catching event as needed and use the Quick Toolbar to add the flow between elements. Likewise, to add start events drag the start event from the shapes toolbar and drop it in the Process Map. Start events are not available in the Quick Toolbar option since their function is to start a process, so no element can add them to continue their flow.

Editing the Label of an Event

By default, events added to the Process Map do not have a label. To add and edit a label, right click on the element and select the option "Edit Label"

The second way to edit the description is to double click on the element which will enable the edition of the text.

Note: The options of the event context menu of the figure vary according to the type of Event.

Deleting an Event from the Process Map

To delete an event from the Process Map right click on the element and select the "Delete" option from the event context menu.

Note: The options of the event context menu of the figure vary according to the type of Event.

The second way to delete events is to click on the element and four white little squares will appear at the corners. This means that the element has been selected. Press the "DEL" key to delete it.

From version 3.0.1, the third way to delete an event from the Process Map is to use the "Quick Toolbar" option. After clicking on the event, click on the garbage icon to delete the event.

Start Events

These events start the process and begin the workflow. Within the design of a process, the position of a start event is usually the first of the entire design, so the process flows top-down or from left to the right.

Within the shapes toolbox, there are two start events available to be easily added even though all types of start events are available to be added in the design of a process.

Take into account that the election of some of these start events is only for designing purposes inside the Process Map. The ProcessMaker engine only supports the "Empty", the "Receive Message" and the "Timer" (from version 3.0.1) start event. To select the type of start event inside the design, right click on any of the start events and select the option "Start Event Type".

Empty (None)

This event simply starts the workflow of the process.

When running a case of this process the start event will initiate the first task of the process.

If a process needs to begin with different activities, it is possible to design processes with multiple starting events. For example, in a process to request supplies, the can be a request for credit in the"Request Credit" task, whereas there could be a direct request for the supply in the “Request Supply” task in the example below.

It is also possible to assign the same user to multiple starting tasks. For example, a user who handles billing might need to decide whether to send a bill, contact the client or consult the supervisor in the following process.

When starting a new case, the user will be presented with the option to select the task where the case should begin. In the list of available processes, the starting task will be listed in parentheses after the process name.

Web Entry

"Empty" start events have the option "Web Entry" available inside its context menu. To learn more about this option for version 3.0 of ProcessMaker check this documentation.

Receive Message

This start event is also supported by the ProcessMaker engine. Use this event when a message, sent by another process, contains data which triggers the start of the flow of the current process. Inside ProcessMaker, this event receives those messages from the Send Message Intermediate Event and the Message End Event using the "Message Types" created for the processes.

As this event waits specifically for a message sent by another process, it is not possible to start manually any case of the process which has this start event. For example, for the two processes of the following design:

Even though the tasks of both processes have already users and steps assigned, notice that the second process only starts when a message is sent from the "Send Contract" (send message intermediate event) of the first process. That's why, if a user who is assigned to the first tasks of both processes accesses "HOME > New Case", the only process available to start cases will be the first one.

Only after the first process sends the message that triggers the start of the second process, the assigned users receive inside their Inbox the first task of the second process.

Configuring the Receive Message Start Event

Take into account that to work with this type of event, the message received must have already been created with the Message Types option of the main toolbox. To configure the event right click on it and select the option "Properties" from the event context menu.

Note: According to the BPMN standard, these events must be part of separate processes represented by different pools in the Process Map.

The modal window that opens has the following characteristics:

  • Message Type: Select the Message Type from the dropdown menu that will trigger the start of the process. The message type selected in this field will define the input variables needed to start the first task of the process. The event which will send the message must have the same message type defined inside its configuration, so when the first process arrives at this event, it will throw the value of the variables to the start event which will trigger the first task sending these values.
  • Store Value In: Define in this column the variables of the current process that will store the value field messages sent from the other process. Each field of the message can be assigned to a correlative existing variable of the current process. To do this correlation, click on "Edit" and the section "Message Content" displays:

    Select the variable in the field "Store value in" by using the @@ button or entering the name of the variable with the @@ prefix.

  • Name Value: This column shows the name of the message field used to store the value of the message sent from the other process. Take into account that these values are not variables used by the first process inside its forms, triggers, input or output documents. These variables are used exclusively by the message between the processes (which means that the sending event should define in its properties the variables that will be sent in the message as well).
  • Correlation Value: The correlation value defines the unique ID that will relate both events: the send message event and the receive message event.
    This value must be the same in both events. The correlation value must be either a fixed value such as correlation = 62521362355f06c223f95d8008656248 (for example) or an unchangeable variable used in the project whose value does not change for both processes such as @@USER_LOGGED (in case the processes are assigned to the same user). This definition will create the case variable that can be used inside the process. Already created variables of the process or system can not be used in this type of process since this event starts the flow of the process and those variables do not have yet a value defined.

Finally, save the changes by clicking on "Save" at the right side of the section.

Receive Message - Running Cases

When running cases of processes that have the Receive Message Start event configured to start the flow of the second process, it is necessary to execute the messageeventcron.php to start pending cases of the process that starts triggered by a start timer event. This file is located at:

Linux:

<INSTALLATION-DIRECTORY>/processmaker/workflow/engine/bin/messageeventcron.php

Windows:

<INSTALLATION-DIRECTORY>\processmaker\workflow\engine\bin\messageeventcron.php

To start pending cases of the Receive Message Start Event open a terminal, go to the file's location and execute the following command:

php -f messageeventcron.php

For more information, see Executing Cron Scripts.

For example, in the following design:

After executing "Task 5" of the first process, the "Send Message" intermediate event will send a message to the "Receive Message" start event in order to start the execution of the second process in "Task 6". To do this both events are configured as follows:

Use the Message Type "MessageType2", already created in the process. Then, set the "Correlation Value" as id = "123456789" in both events.

Start a case of the first process. After task "Task 5", the send message intermediate event will send the message "MessageType2" to the receive message start event of the second process to start a new case of that process.

To start the pending cases of the second process run messageeventcron.php file. The message shown is like the following:

To work with the case created to the Inbox of ProcessMaker and open the case.

Note: The figure of the process is presented only to explain the functionality of the event when running cases. For a "real-case" example check the example at the end of this page.

Start Timer Event

The Start Timer Event provides a way to automatically start new cases at specified times. These cases can be programmed to be started on an hourly, daily, weekly or monthly basis or one time only.

To add a Start Timer Event to the design, drag and drop a Start Timer event from the Shapes toolbox:

If there is already a start event in the process, right click on the event and select Start Event Type from the context menu, then select the "Timer" option.

A process containing a Start Timer Event must have at least one task. The initial task after a Start Timer Event needs to be assigned to at least one user. Start Timer Events do not work correctly if the initial task is a script task.

In the following process, the Start Timer Event will automatically start cases in the "Audit Monthly Purchases" task, when the event is executed by the timereventcron.php script.

If needing to manually start cases in this process using the ProcessMaker graphical interface, a normal Start Event can be added to the initial task, in addition to the Start Timer Event. Any user assigned to the "Audit Monthly Purchases" task can login to ProcessMaker and manually start a case.

Note: The initial task in a case started with a Start Timer Event will have a delegation index of 2, because the event is considered the first delegation in the task.

Configuration

To configure a Start Timer Event, right click on the event and select Properties from its context menu. The following configuration will display:

Select how often the case will be started:

  • Hourly: A case will be created on an hourly basis. Enter the minutes of the hour, when a new case will be started. For example, 20 means a new case will be started twenty minutes after every hour in the day. Also define the Start Date when new cases will start being created. If new cases should stop being created after a specified date, then enter the optional End Date.

  • Daily: Cases will be automatically started on a daily basis.

    Where:

    • Start Date: Select a date when new cases will begin to be created.
    • End Date: Select a date when new cases will stop being created. If no date is selected, then new cases will be created forever.
    • Hour: Select the hour when the new case will start.
    • Minute: Select the minute(s) of the hour when the new case will start.
    • Select the day(s) of the week: Select the days of the week when new cases will automatically start.
  • Monthly: Cases will be automatically started on a monthly basis.

    Where:

    • Start Date: Select a date when the cases will begin to be scheduled.
    • End Date: Select a date when the cases will stop being scheduled. If no date is selected, then cases will continue being scheduled forever.
    • Day: Select the day when the case will start. Days are represented in numbers where 1 corresponds to Monday.
    • Hour: Select the hour the case will start.
    • Minute: Select the minute(s) the case will start.
    • Of the month(s): Select in which months cases will be automatically started.
  • One date/time: A case will be automatically started only once.

    Click inside the Date time field and the following picker will display:

    Choose the specific date and time the case will start.

  • Every: A case will be created automatically EVERY hour. Also, it is possible to configure hour, minutes and seconds by dividing time, it means when an hour is set it is completed with .00, and if seconds need to be set just enter 0.01.

Start Timer Event - Running Cases

When running cases of processes that have the Start Timer Event configured to start the process, it is necessary to execute the timereventcron.php script on the ProcessMaker server to start any pending cases of the event. This file is located at:

Linux:

<INSTALLATION-DIRECTORY>/processmaker/workflow/engine/bin/timereventcron.php

Windows:

<INSTALLATION-DIRECTORY>\processmaker\workflow\engine\bin\timereventcron.php

To start pending cases of the Start Timer Event, open a terminal, go to the file's location, and execute the following command:

php -f timereventcron.php

For more information, see Executing Cron Scripts.

Note: The events will continue only after the timereventcron.php script is executed even if they are overdue.

The message shown in the terminal is like the following:

The new case should appear in the user's Inbox in ProcessMaker in the second task in the process.

Note: Make sure that the ProcessMaker Time Zone is the same as the date.timezone set in the server's php.ini file. See Events Troubleshooting below.

Conditional

Use this event if the start of the process depends on the evaluation of a condition or a rule. This condition must be independent of the process (es). The process will start if and only of the evaluation of said condition evaluates to TRUE.

As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Signal

Use this start event in the designing of the process if a signal is received from another process which triggers the start of the process. This event is different from a Receive Message Start Event because the latter needs a specific recipient while a signal can be triggered by anyone who receives it and reacts to it which means it has multiple recipients.

As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Intermediate Events

An intermediate event represents a point of time at which some matter occurs within a process that is being executed, i.e. an interval between the start of an individual process and its end. Thus, an intermediate event itself does not start or terminate a process. Intermediate events catch conditions or situations that cause events or they throw such conditions. In other words, intermediate events have characteristics of both Catch and Throw Events and they are represented by a double border circle.

ProcessMaker 3.0 has implemented 2 types of intermediate events:

Intermediate Throwing Event

In version 3.0 of ProcessMaker, these events are represented by a double circle with a dark envelope inside it in the shapes toolbox which is the intermediate email event.

During the execution of a process, different events, such as messages, can be thrown using this event. Intermediate "throwing" events are caught by Catching events but are processed asynchronously. This means the process that contains the send message event does not stop until it is caught somewhere else.

Inside the Process Map it is possible to add the following intermediate throwing events:

Email Message

Available Edition: Available only in the Enterprise Edition.

Use this event to send a notification during the execution of a process. To add an email message event, drag and drop the intermediate event directly from the shapes toolbar and connect it to the other elements in the process, or add an intermediate event from the "Quick Toolbar" option of the elements and change its type to "Email Message" from the event context menu. Right click on the event, select the option "Properties" and configure the event in the following window:

Where:

  • From: Required Field. Select the email address from where the email will be sent. The dropdown lists all the available email accounts registered in the configuration of the workspace. Check this documentation to learn more about it.
  • To: Specify an email, this must be a string or a process @@variable (which could specify a group of emails addresses). At least one email specification is required. Use commas to separate more than one email address.

    Note: The issue when using @@ variables in this field in which emails are not sent is fixed from version 3.0.1.4.

  • Subject: Not Required. The email subject.
  • Content: Required Field. The body of the email contains the details of the email. Press CTRL + @ to display the list of available variables in the process. To learn more about this editor check this documentation
  • Cancel: Cancel the configuration of the email. All changes will be lost.
  • Save: Save the changes of the email. Note that the email is not send with this action. The email is sent when the case is executed.

When running cases, this event does not need any additional configuration or the execution of any cron in ProcessMaker. It directly sends the email when this event is reached in the flow.

Email Message - Known Issues

Take into consideration the following known issues:

  • If working with ProcessMaker 3.0.4, take into consideration that if a process design contains an Intermediate Email Event after a Parallel gateway (as in the image below), an error may be displayed randomly when the second case is executed.

    This is a known issue that has been fixed in later versions.

  • There is a limitation when using the Intermediate Email Event after an Intermediate Timer Event, the process will NOT work properly on designings such as:

    Workaround: To fix this limitation, the Intermediate Email Event can be replaced by an Script Task which can send the email with a trigger.

    Notice that if the Intermediate Email Event is executed before the Intermediate Timer Event, the process will work correctly.

Send Message

Use this type of event in the designing of a process to send a message during the execution of the process to another process that will require the message. The ProcessMaker engine catches this message using an receive message intermediate or by a receive message start events. These events must be part of separate processes represented by different pools in the Process Map.

Order for these events to work correctly, the message must be passed between different processes which are inside separate pools (not between lanes in the same pool). The message must have already been created with the Message Types option and the configuration of this event must be made inside its "Properties".

The modal window that is opened has the following characteristics:

  • Message Type: Select the Message Type from the dropdown menu that will be related to this send message event. The message type selected in this field will define the variables sent to the other process. The event which will receive the message must have the same message type defined inside its configuration.
  • Name: This column shows the message field name used to stored the value of the message that will be sent to the other process. Take into account that these values are not variables used by the process inside its forms, triggers, input or output documents. These variables are used exclusively by the message between the events.
  • Get Value from: Define in this column the variables used in the process from where the values will be obtained and used by the message that will be sent to the other process.
  • Correlation Value: Define the unique ID that will relate both events: the send message event and the receive message event or start message event.
    This value must be the same in both events. The correlation value must be either a fixed value such as id = 123 (for example) or an unchangeable variable used in the project whose value does not change for both processes such as @@USER_LOGGED (in case the processes are assigned to the same user). This definition will create the case variable that can be used inside the process. Already created variables of the process or system can not be used in this type of process since this event starts the flow of the process and those variables do not have yet a value defined.

Send Message - Running Cases

As this event only sends messages to other events, the flow in the process continues normally after this event has sent the message. To learn how to continue the other processes configured, check section "Running Cases" for "catching" events.

Note: To view an example of how to run a case of this event, check the example at the end of the page.

Signal

Use this element to send a notification from one process to another. As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Intermediate Catching Events

In version 3.0 of ProcessMaker, these events are represented by the timer event in the shapes toolbox.

To add them in the design on the Process Map, it is necessary to drag and drop them from the shapes toolbox since its shape is not available in the "Quick Toolbar" option of the elements.

The process awaits an event, e.g the incoming of a message, and stops until the event is "caught". An event can be caught when it is thrown somewhere else. Though an Intermediate Timer cannot be thrown, is can only be caught as the time is a somehow external influence to the process.

Inside the Process Map it is possible to add the following Intermediate Events. However, take into account that the engine of ProcessMaker supports only the receive message and the timer events in the execution of the process even though the rest of receive message intermediate events are also available for designing.

Receive Message

Use this type of intermediate event inside the designing of a process to receive a message sent from another process. This element is used to pause the process flow until the message arrives. Inside the ProcessMaker engine, this event receives those messages from the Send Message Intermediate Event and the Send Message End Event.

Remember that according to BPMN 2.0 rules, messages can only be sent between two different processes which, in ProcessMaker, would be represented by two different pools (To view an example check the example at the end of this page). To have the relationship between two processes, both of them have to be configured.

Configuring the Receive Message Event

Take into account that to work with this events, the messages received must have been already created with the Message Types option and the configuration of this event is made inside its "Properties".

The configuration of the event is made inside the modal window that opens which has the following characteristics:

  • Message Type: Select the Message Type from the dropdown menu that will be related to this intermediate event. The message type selected in this field will define the input variables needed to continue the flow of the process. The event which will send the message must have the same message type defined inside its configuration, so when the message of the first process arrives at this event, it will throw the value of the variables which the receive intermediate event will use as variables of the process to continue the case.
  • Store Value In: Define in this column the value of the variables of the process that will receive the message from the other process. Each variable on the message can be assigned to a correlative existing variable of the process. To do this correlation, click on "Edit" and the section "Message Content" displays:

    Select the value in which the variable will be stored in the other process selecting it by using the @@ button or entering the name of the process with the @@ prefix.

  • Name Value: This columns shows the name of the variable used to stored the value of the message sent from the other process. Take into account that these values are not variables used by the first process inside its forms, triggers, input or output documents. These variables are used exclusively by the message between the events.
  • Correlation Value: The correlation value defines the unique ID that will relate both events: the send message event and the receive message event.
    This value must be the same in both events. The correlation value must be either a fixed value such as id = 62521362355f06c223f95d8008656248 (for example) or an unchangeable variable used in the project whose value does not change for both processes such as @@USER_LOGGED (in case the processes are assigned to the same user). This definition will create the case variable that can be used inside the process. Already created variables of the process or system can not be used in this type of process since this event starts the flow of the process and those variables do not have yet a value defined.

Receive Message Event - Running Cases

When running cases of processes that have Receive Message intermediate events configured to continue the flow of a second process, it is necessary to execute the messageeventcron.php script on the ProcessMaker server to continue pending cases of the event. This file is located at:

Linux:

<INSTALLATION_DIRECTORY>/processmaker/workflow/engine/bin/messageeventcron.php

Windows:

<INSTALLATION_DIRECTORY>\processmaker\workflow\engine\bin\messageeventcron.php

To continue pending cases of this event open a terminal, go to the file's location and execute the following command:

php -f messageeventcron.php

For more information, see Executing Cron Scripts.

Note: To view an example of how to run a case containing this type of event, see the example at the end of this page.

Intermediate Timer Event

The intermediate timer event represents a delay in a flow depending on a certain time defined in the configuration of a process. This event is a "catching" event since it must wait for an specified time to trigger and continue the flow. For instance, if a user does not pay the bills within 30 days a notification will be sent to him.

To add an intermediate timer event, drag and drop the event to the Process Map and connect it to the respective tasks in the process. Follow the example below a diagram would be:

Intermediate Configuration

Right click on the event and the configuration window will open

Where:

  • Wait for: Select the number of minutes, hours, or days the flow must wait. At least one of these fields must be selected (minute, hour or day). The wait status begins when the flow arrives at the intermediate timer event.
  • Wait until the specific date/time: Select a specific date and time the flow must wait.

Intermediate Timer - Running Cases

When running cases of that use this event to continue the flow of the process, it is necessary to execute the timereventcron.php script on the ProcessMaker server to continue pending cases of this event. This file is located at:

Linux/UNIX:

<INSTALLATION_DIRECTORY>/processmaker/workflow/engine/bin/timereventcron.php

Windows:

<INSTALLATION_DIRECTORY>\processmaker\workflow\engine\bin\timereventcron.php

To continue pending cases, go to the file's location and execute the following command:

php -f timereventcron.php

For more information, see Executing Cron Scripts.

Note 1: The events will continue only after the timereventcron.php script is executed even if the cases are overdue.

Note 2: Make sure that the ProcessMaker Time Zone is the same as the date.timezone set in the server's php.ini file. See Events Troubleshooting below.

Conditional

Use this event to indicate a point in the process where a condition will be evaluated. If the condition evaluates as TRUE, the flow should continue. If it evaluates as FALSE, then the case should be stopped.

Conditional intermediate events are not yet supported by the ProcessMaker engine, so they are currently used only for designing purposes.

Signal

Use this event to send a notification from one process to another. This event is not yet supported by the ProcessMaker engine, so use it only for designing purposes.

End Events

This event terminates the process, so the case ends and its status is set to "completed". If the case has multiple parallel paths, then all paths in the case will be ended. It is recommended to place the end event at the bottom of the Process Map if using a top-down design or on the right hand side of the Process Map if using a left-to-right design.

Inside the Process Map it is possible to add the following Receive Message Intermediate Events:

Take into account that the ProcessMaker engine support only Empty (none) end events. The other end events have been added only for designing purposes. To select the type of end events inside the design, right click on any of the start events and select the option "Type".

Empty (None)

A process can contain multiple End Events. For example, in the following equipment maintenance process, the process ends either when the equipment check concludes that the equipment is OK or when new equipment is bought. If the equipment is refurbished, the process will loop to recheck the equipment.

Message Event

This event terminates the process and sends out an message to the Receive Message Start Event and the Receive Message Intermediate Event. It is represented by a circle with a bold border around a green envelope.

A process can contain multiple End Events. For example, the following process is used to decide whether to produce a new product. If the new product will be produced, then a brochure is created and the process ends when the brochure is sent out in an email. If the product won't be produced, then the process immediately ends without producing a brochure.

Configuring the End Event

To work with these events, the messages sent by this end event must have been already created with the Message Types option. To configure an end event, right click on the event and select "Properties" from its context menu.

The dialog box that opens has the following characteristics:

  • Message Type: Select the Message Type from the dropdown menu. The message type selected in this field will define the variables sent to the other process. The event which will receive the message must have the same message type defined inside its configuration.
  • Name: This column shows the name of the variable used to stored the value of the message sent from the other process. Take into account that these values are not variables used by the first process inside its forms, triggers, input or output documents. These variables are used exclusively by the message between the events.
  • Get Value From: Define in this column the variables used in the process from where the values will be obtained and used by the message that will be sent to the other process.

  • Correlation Value: The correlation value defines the unique ID that will relate both events: the send message event and the receive message event.
    This value must be the same in both events. The correlation value must be either a fixed value such as IUD = 98765433 (for example) or an unchangeable variable used in the project whose value does not change for both processes such as @@USER_LOGGED (in case the processes are assigned to the same user). This definition will create the case variable that can be used inside the process. Already created variables of the process or system can not be used in this type of process since this event starts the flow of the process and those variables do not have yet a value defined.

Message End Event - Running Cases

As this event only sends messages to other events, the flow in the process ends after this event has sent the message. To learn how to continue the other processes configured, check section "Running Cases" for these processes.

Note: To view an example of how to run a case of this event, check the example at the end of the page.

Email Message

Available Edition: Available only in the Enterprise Edition.

Send a notification as soon as the flow finishes. To add an email message drag and drop the end event, make sure that this is an Email Message type, then connect it to the respective tasks. Right click over the task and select Properties the following interface will appear:

Where:

  • From: Required Field. List the available email accounts registered in the workspace configuration.
  • To: Specify an email, this must be a string or a process @@variable (which could specify a group of emails addresses). At least one email specification is required. Use commas to separate more than one email address.

    Note: The issue when using @@ variables in this field in which emails are not sent is fixed from version 3.0.1.4.

  • Subject: Optional. The email subject.
  • Content: Required Field. The body of the email contains the details of the email. Press CTRL + @ to display the list of available variables in the process.
  • Cancel: Cancel the configuration of the email. All changes will be lost.
  • Save: Save the changes of the email. Note that the email is not send with this action. The email is sent when the case is executed.

Note: Use this element to send emails and end the flow of the process rather than using two different elements, one to send an email and another to end the flow (which is currently not supported by the engine).

Error

Use an Error End Event in the design of the process to indicate that during the flow of the process the might be an error which could affect the normal execution of the flow and throws an exception. This element will indicate that the end of the process at that point is due to an exception and caught by that event.

As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Signal

Use this end event in the design of the process to indicate that a signal will broadcast when the end of the process has been reached. The signal sent by the process can be received by any other process which needs that signal to trigger an event. As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Terminate

Use this event in the design of the process if there are parallel tasks to be executed at the same time and the completion of one of them is enough to end the entire flow of the process. Thus, this event will end immediately all execution in the process. As this event is not supported by the ProcessMaker engine, use it only for designing purposes.

Events - Example

Let's take the following design where the first process, inside the "Contracting Firm" pool starts a case with the "Negotiate Contract" task, then it sends a message through a send message intermediate event which triggers the second process inside the "External Auditor" pool. As you can see in the design, when the second process reaches the send message intermediate event, at the end, it throws a message which returns to the first event of the first process, which has remained paused waiting for this message before continuing its execution.

The message types created for these processes are the following:

  • Message type for the "Send Contract" send message intermediate event and the "Receive Contract" receive message start event.

  • Message type for the "Send Verified Contract" send message end event and the "Receive Verified Contract" receive message intermediate event.

Each task in the example has its own steps (DynaForms, triggers, Output and Input documents) assigned for end users to work with them during the execution of the process. Since this example is intended to show the functionality of the events, the steps of the tasks will not be shown in the explanation.

The configuration of the "Send Contract" send message intermediate event is the following:

The configuration of the "Receive Contract" receive message start event is the following:

The message type used is "ContractMessage" which will store values from one of the steps of the first task on the first process in the pool "Contracting Firm" in the event "Send Contract" will send the values of these variables through the message to the other process in the pool "External Auditor" and will be received by the event "Receive Contract" which will assign the values sent in the message to its own variables used in the process and will start it.

The configuration for the "Send Verified Contract" at the end of the second process in the pool "External Auditor" which will send the information of the Legal and Accounting department before signing the contract, is the following:

The configuration of the catching event "Receive Verified Contract" which will receive the message from the second process to continue the contracting process is the following

Now, let's run a case of the process. Take into account that this example is only intended to show the execution of the events for both processes. To start the process go to "Home > New Case > Contracting Process (Negotiate Process)"

The steps of the first task "Negotiate Contract" will be executed and after that, the send message event "Send Contract" will send the "ContractMessage" message to the second process in the pool "External Auditor" to start a new case of it. Then, the flow will go to the "Receive Verified Contract" that will pause the case until a message is sent from the second process. This event will show the following message to indicate that:

After clicking on "Continue", the task "Authorize Contract" will not be shown in the Inbox of the assigned until the messageeventcron file is executed and messages are received by the events.

In the second process the message start event "Receive Contract" will catch that message from "Send Contract" event and start a new case of this process after the cron is executed. Let's execute the cron.

Now, the person assigned to the first task will receive the case in his/her Inbox.

To continue the entire "Contracting Process", the second process must be completed until the end event "Send Verified Contract" is reached and it sends a message to the "Receive Verified Contract" to continue the execution of the first process. After the second process ends, the cron must be executed again:

The message in console Total cases continued: 1 indicates that the case is now listed in the inbox of the user assigned to the task "Authorize Contract":

From there on, the case must simply continue the execution of the rest of the tasks, until the end of event is reached as well.

Events Troubleshooting

For message events, the message type between both processes must be the same. Cases in processes whose events are not well configured can not be recovered.

For events that have not been well configured, when running the messageeventcron file, the message shown for these cases is the following:

In order for Start Timer and Intermediate Timer Events to work correctly, the time zone must be the same in all three places:

  1. The date.timezone setting in the php.ini file on the ProcessMaker server.
  2. The Time Zone found at Admin > Settings > System in ProcessMaker (or time_zone in the env.ini file on the ProcessMaker server).
  3. The time zone of the ProcessMaker server.

    Note: The time zone on Linux/UNIX machines can be found with the date command: $ date Wed Oct 12 16:49:26 BOT 2016

If the time zones are different, then Start Timer Events will not initiate new cases, and cases with Intermediate Timer Events will not advance.

For example, if using Eastern Standard Time in the US, then set the php.ini file on the ProcessMaker server to use the following configuration:

[Date] ; Defines the default timezone used by the date functions ; http://php.net/date.timezone date.timezone = America/New_York See this list of available time zones. After changing the php.ini file, then restart the Apache server for the new setting to take effect.

Then, login with a user such as "admin" who has the PM_SETUP_ADVANCE permission in his/her role and go to Admin > Settings > System. Set the Time Zone to America/New_York.

If not wishing to use the graphical interface to set ProcessMaker's time zone, it can also be set in the env.ini configuration file, which is automatically created when a user clicks on Save in the Admin > Settings > System page. This env.ini file can also be manually created to set the time zone. When the timereventcron.php script it executed, it will use the time zone set in the env.ini file to process the timer events in the pending cases.

If an error occurs while executing one cron scripts, then it will be logged in the shared/log/cronError.log file, which is created the first time an error occurs.