The Process Map

The Process Map is a grid area where business processes are laid out in a visual manner so they can be easily designed and their progress tracked at a glance. The Process Map uses a graphical drag-and-drop interface which allows elements to be easily added and deleted and rearranged. Right click contextual menus provide options for modifying the objects once they have been added to the map. Using the Process Map is a good way to clarify how the different people and departments in your organization will work together and to specify a logical order for decision making, approving requests, delegation of responsibilities, and fulfilling the necessary tasks to complete a process. The Process Map is designed to help you visually set up processes and their tasks, and then begin defining steps for each task.

Tips for using the Process Map:

Since ProcessMaker is a web-based application, it may occasionally have trouble exiting dialog boxes in the Process Map. If ProcessMaker hangs when displaying a dialog box, return to the main Process Map by clicking the refresh button on your web browser.

The Process Map does not offer an undo option and does not allow you to save different versions of the map. If you anticipate experimenting with the map, but might possibly want to return to a previous version of the map afterwards, it is a good idea to export the process before making any changes. To return to a previous version of the map, delete or rename the current process and then import the previous version.

Creating a Process

Login as the "admin" user or another user which has the PM_FACTORY permission in its role, so it can edit processes. Go to the PROCESSES menu, and click the New link at the top left of the list of processes.

Enter a name and a description for the new process and click Save.

Start with an existing Process

The easiest way to begin working with ProcessMaker is to import an existing process and adapt it to your needs. Click on the Import link and select an existing process to import. (Process files have a .pm extension.)

ProcessMaker provides a number of sample processes which can be downloaded for free from the ProcessMaker Library. To see the list of processes available for free download, click on the Browse Library link and select a process from the list.

To download one of the processes, click on the View link to the right of the process. In the dialog box which provides information about the process, click on the Download at the bottom, to automatically download and import the library.

The Map's Right Click Menu

To start designing a process and adding elements to the Process Map, right click anywhere in a blank area on the map and select an option from the menu.

Edit Process: This option allows the process name and its description to be modified. It also provides options to activate Debug Mode and set a calendar for the process.

Add SubProcess: Sub-processes allow cases to be run as a subprocess inside of a master process.

Add Text: Additional text labels can be added to the Process Map. This text can be used to label a set of tasks, identify departments in the organization, explain the routing logic, or even provide guidance to the user.

Horizontal Line: Adds a horizontal line to the Process Map, to help visually divide up the process. Lines can be used to separate tasks or departments of your organization into logical groupings on your Process Map.

Vertical Line: Adds a vertical line to the Process Map, to help visually divide up the process. Lines can be used to separate tasks or departments of your organization into logical groupings on your Process Map.

Delete All Lines: This option will delete all horizontal and vertical lines on the Process Map.

Process Permissions: Use Process Permissions to give specific users read-only access to information about cases. (For write access to cases, see Process Supervisors.) Process Permissions can be defined, so specific users can view or not view specified objects in cases, such as DynaForms, Input Documents and Output Documents.

Process Supervisors: Process Supervisors are designated users who can access cases from the process and change the case data in DynaForms and Input Documents, without being assigned to particular tasks in the process. Use this submenu to specify what objects the Process Supervisors can access.

Web Entry: Web Entry is an option to initiate new cases from a DynaForm displayed in an external web page.

Case Tracker: The Case Tracker allows external users to follow a case's progress and access information about that case through a case code and PIN. Use this submenu to specify what objects the external users are allowed to see in the Case Tracker.

Process Files Manager: Use the Process Files Manager to load external documents into ProcessMaker. Unlike Input Document files, which often change for each new case, this option is generally used for files which are unchanging and needed by all the cases in a process. The Process Files Manager can also create email templates which are used to send notifications.

Events: Events allow a trigger to be fired or an email to be sent at a specified time during a process.

Defining Tasks

The first step in creating a Process is to define the tasks. In ProcessMaker a task is a logical group of sequential steps, sharing a common goal. Tasks can be assigned to different users or groups of users, so that a process can be used to coordinate the activities of different people or groups in an organization.

To create a task, right click on the a blank area on the process map and select the option Add Task from the menu. The task will be added to the ProcessMap at the location of the mouse pointer. The task can be moved on the map by clicking on it and dragging while holding down on the mouse.

To modify a task, right click on the task to select an option from the Task menu:

Steps: In ProcessMaker a step is a piece of work that forms a clearly defined action within a task. Select this option to add a step to the task. See the section Defining Steps.

Users & User Groups: Select this option to assign the task to user(s) or group(s), who will have permission to access and fulfil the task. See the section Assigning Tasks.

Users & User Groups (Adhoc): Select this option to assign user(s) or group(s) to a task on an ad hoc basis. The normally assigned users to a task can reassign the case to any user or group who has been assigned ad hoc. See the section Assigning Tasks.

Derivation Rules: Derivation rules, which are also known as routing rules will control the flow of work from one task to the next. See the Defining Routing Rules section.

Properties: Select to define many aspects of how a task is handled, such as how to transfer assignment to different users, time limits, notification to users, the case variable, whether a starting task, ad hoc assignment when errors, and label definition for the case. See the section Configuring Tasks

Task Warnings

Since version 1.2-3994Beta, task warnings have been added. The warnings are important because they will help designers notice if a task has steps and users assigned to it. When a task is created, it will have this icon on the upper right hand.

There are three cases for the warning to remain in the task:

1. When the task does not have any assigned tasks and steps:

2. When the task does not have any assigned users:

3. When the task does not have any assigned steps:

The warning icon will disappear once user(s) and step(s) have been assigned to the task.

Defining Routing Rules

Routing rules, which are also known as derivation rules, control workflow between tasks in a process. In other words, they determine which is the first task in a process and how work moves to the subsequent tasks, and so on until the process ends. Routing rules can move the workflow along a single path or divide the workflow into multiple threads. They can also evaluate conditions to determine which are the subsequent task(s) and even send the workflow down subprocesses, which are separate workflows with their own set of cases.

Types of Routing Rules:

Sequential: When one task is completed, a sequential routing rule will move the workflow directly to subsequent task(s).

Selection: A selection routing rule allows the user assigned to the task to manually select the subsequent task(s) to be performed in the process.

Evaluation: An evaluation routing rule uses a condition (which is a true or false expression in PHP) to decide whether the workflow moves to subsequent task(s).

Parallel (Fork): A parallel (fork) routing rule divides the workflow into two or more parallel tasks.

Parallel By Evaluation (Fork): A parallel by evaluation routing rule uses a condition to decide whether to divide the workflow into two more parallel tasks.

Parallel (Join): A parallel (join) routing unites multiple parallel tasks in the workflow that had previously been divided by a parallel (fork) routing. All the parallel tasks must be completed before a parallel routing can take place.

End of Process: End of process marks where to terminate the workflow.

Starting Task: Starting task marks where to begin a process.

Applying routing rules

Routing rules are applied to specific tasks (and ProcessMaker even treats them as task objects). To apply a routing rule to a task, click on an icon in the Routing Rules Toolbar and drag the icon to the task while still holding down on the mouse button. Release the mouse button over a task to attach the routing rule to that task.

Then drag the routing rule, which is shown as a red connector dot, to the subsequent task while still holding down on the mouse button, then release over the subsequent task to connect the two tasks.

If the work can flow down multiple threads (paths) in the process, drag and drop additional routing rules from the toolbar to connect them as well.

To change a routing rule to a different type, simple drag a routing rule from the toolbar and drop it on the task with an existing routing rule. When asked "Are you sure you want to change the derivation rule?", click Accept to change the type of routing rule.

Once a routing rule connects tasks, it can be edited by either clicking on the routing rule symbol in the Process Map or by right clicking on a task and selecting the option Derivation Rules from the menu.

Starting Task Routing Rule

Every process must have at least one Starting Task routing rule which indicates which task should start the process. Either drag and drop the icon from the toolbar to a task or right click on the task and select the option Properties from the dropdown menu. Under the Definition tab, mark the checkbox Starting Task.

Processes can have multiple starting tasks and even multiple work paths. For instance, an organization with a Sales department might want to start its "Invoice Process" at two different points: either by first contacting the client or by first sending a quote. In addition, it might want to start the "Invoice Process" with a different work path in the Finance department. If Sales is handling the invoice, then different tasks are executed than if Finance is handling it.

If a process has multiple starting tasks, then the person who starts the case may select which task starts the process. In the dropdown box, the name of the process is provided followed by the name of the starting task in parenthesis.

End of Process Routing Rule

All processes must have at least one task with an End of Process routing rule to terminate the process. There can be multiple ending points to any process. To add an End of Process routing rule to a task, drag and drop the icon from the toolbar to a task or right click on a task which has an evaluation or selection routing rule and select the option Derivation Rules. Click the New link to add a routing rule, then in the dropdown box, select the option "End of process".

Sequential Routing Rule

With a sequential routing rule, workflow automatically flows to subsequent tasks, so no special configuration is required, after connecting the tasks.

Selection Routing Rule

A selection routing rule allows the user assigned to the task to manually select which task will be the next in the workflow. After completing a task, the user will be presented with the available subsequent tasks and asked to choose one.

For instance, if creating a process to handle billing in dollars and Euros, a selection routing rule could be used to decide whether to generate a bill in dollars or in Euros.

After adding the selection routing rule, double click on the routing rule to add "Descriptions" to the selection routing rule explaining why to choose the "Billing Dollars" and "Billing Euros" tasks.

These descriptions will help the user decide which task to choose when running a case:

Evaluation Routing Rule

An evaluation routing rule uses a condition to decide whether the workflow moves to subsequent task(s). If the condition, which is a PHP expression, evaluates to true, then the workflow will move to the subsequent task. For more information on how to create conditions which will evaluate to true or false, see Using Conditions.

An evaluation routing rule is commonly used to decide between multiple tasks. If all the conditions are false then a case will never complete. If all the conditions are true, then the workflow will move to all the subsequent tasks, which may not be what is desired. Therefore, it is very important to test conditions and make sure that they don't yield unexpected outcomes.

The previous example of a billing processes could also be implemented with an evaluation routing rule instead of a selection routing rule.

If a DynaForm is filled out in the "Initiate Billing" task, the user can select whether the bill will be in dollars or Euros.

The choice of dollars or is be stored in the variable @@Currency which could be used in the conditions for the routing rule. Click on the evaluate routing rule in the Process Map and add the conditions.

If you get the following error message when running a case with an evaluation routing rule, check to see that you have defined a condition.

If a condition exists, then the problem is probably due to the fact that the condition contains an undefined variable. Verify that the variable exists, by clicking on the [ @@ ] button find the variable in the list of available variables. Remember that variable names in PHP are case sensitive.

If the variable was defined in a DynaForm, then the problem is that the values which are being entered into the DynaForm aren't being saved to variables. To allow your users to save their entered data in the Dynaform, add a Submit button to the DynaForm. To remind users to click the Submit button, go to the Properties tab of the DynaForm Designer and select the option "Show Prompt" for Next Step Link. If you want the data to be automatically saved to variables without the hassle of clicking the Submit button, select the option "Save and Continue".

Parallel (Fork) Routing Rule

A parallel (fork) routing rule divides the workflow in multiple threads (branches) which operate concurrently. Once the task has been completed the workflow will take different sub-threads starting at the same time.
As an example, in the credit card application, where two parallel tasks will take place, because the facility officer sends a request for employment and credit checks.

Once the parallel (fork) rules have been added, by double clicking on the routing rule you can see the following illustration. There it is possible to define more parallel tasks.

In order to ensure the workflow continues only when every parallel task is finished, they need a parallel Join. For this reason, drag and drop the derivation on the first parallel task defined and connect it to the next task. Repeat this step for every task that used the parallel (fork) rule derivation.
The description in the parallel (fork) will show what we have in the next illustration, so we know the task has been derived two times (this will depend on the number of parallel assignation we made).

Parallel by Evaluation (Fork) Routing Rule

A parallel by evaluation (fork) routing rule divides the workflow in multiple paths, evaluating the condition for each of the paths to determine which ones will be executed. A path will only be executed if its condition evaluates to true. If false, it won't be executed, so make sure that at least one of the conditions evaluates to true to avoid errors. For more information on how to create conditions which will evaluate to true or false, see Using Conditions.

All of the sub-paths between the parallel fork and the parallel join must finish executing, before the workflow can move on to the next task after the parallel join.

For instance, if creating a process to handle reporting expenses, where the employee will fill out a form and send it. We will use a parallel by (fork) to evaluate the report expense.

After adding the parallel by evaluation (fork), double click on the routing rule to add “Descriptions”, explaining when the task “Local Manager Approval”, “Regional Manager Approval” and/or “CEO Approval” will be started. When this conditions are being evaluated there can be more than one evaluated true, if that happen then one or more task will be started.

These descriptions will show the user the path the task will be taking, when the case is running.

To ensure that the workflow continues all of the sub-threads need a parallel join to connect them to the next task. Only when all the true evaluated task(s) have been finished the subsequent task will start.

Defining Steps

In ProcessMaker a step is a piece of work that forms a clearly defined action within a task. A step can be a manual action such as filling out a DynaForm or uploading a Word document to use as an Input Document, or it can be workflow action which is automated. There are 4 types of steps in ProcessMaker: DynaForms, Input Documents, Output Documents and Triggers.

To view the steps assigned to a task, right click on the step in the ProcessMap and select Steps from the menu. In the 'Steps Of:' dialog box which appears, a list of the steps in the task will be displayed. The steps will be executed in the order which they are displayed. Click the Up and Down links to change the order of the steps. To remove the step from the task, click the Remove link. If the step is an editable object such as a DynaForm, then an Edit link will also be displayed next to the step, allowing the object to be edited.

To add a new step to a task, click New at the top of the list. If you want the step to be a DynaForm, Input or Output Document, you will have to have already created it previously. Chose it from the list of available DynaForms, Input and Output Documents and click its Select link to add it as a task. If the step is an DynaForm, there is a dropdown box to select whether the form is view-only or whether the user can enter data into form.

Defining Conditions

A condition for each step can also be defined, which is a PHP expression. The step will only be executed if the condition evaluates to True. Remember that in PHP, an expression is True if evaluates to a non-zero value, so -10, 10.23, "10", and "hello" are all True; while "", 0, and "0" are all False. Variables can be used in the expression, allowing the process to check different factors when deciding whether to execute a step or not. For more information, see Using Conditions.

To add a condition to a step, go to the Conditions tab in the "Steps Of:" dialog box and click the Edit link next to a step. In the dialog box, enter the PHP expression. Use the [ @@ ] button to view what variables are available and insert them in the expression. Then click Save to add the condition.

Complex conditions can be constructed using Boolean operators (and, &&, or, ||) and parentheses ( ) to group conditions. In the example above, an input document is only required if the no comment was provided in the DynaForm or if the shipping date is before the present date, which is obtained with the date("Y-m-d") function. The strtotime() function converts a string to a date, so that it is possible to compare the two dates and determine which is earlier.

Adding Triggers

If you want the new step to be trigger, click on the Triggers tab in the 'Steps Of:' dialog box. There will be an option to add the triggers before and after each DynaForm, and Input and Output Document is executed as a step in the task. If a particular variable needs to be defined by a trigger to be used in a DynaForm or document, then fire the trigger before executing the step. If a variable is defined in a DynaForm or document which will be used in a trigger, then fire the trigger after executing the step.

In addition, triggers can be fired before the assignment of the task to a user or group. If the trigger will define a variable which determines who will be assigned the task, insert the trigger before assignment of the task. Likewise triggers can be fired after a task has been completed. The trigger can be executed either before or after the routing rule (derivation rule) is applied to move to the next task in the process.

Click on the [+] next to the step to view its triggers. Before adding a trigger to a step, you will first need to have created the trigger. See the Triggers section for information on how to create triggers. To add a trigger to the step, decide whether when it should be executed and click on [+] next to the desired timing. In the expanded panel for a particular timing, click on Add.

In the dialog box which appears, select an available trigger from the dropdown box. A condition can also be added to determine whether the trigger should fire or not. Then click Assign to add the trigger to the step.

Configuring Tasks

ProcessMaker offers a variety of configuration options for tasks. To configure a task, right click on a task in the Process Map, and select the option Properties from the menu.

Task Definition

In the Definition tab, the general information about a task and its priority can be modified.

Title: The title or label of a task, which is displayed on the Process Map. This field is a short description of the task. This text will show up in the Process Map, so it should be kept short, yet descriptive.

Description: The description for a task. This description is displayed when the user clicks on the INFORMATION tab when running a case and then clicks on the Task Information button in the dialog box which appears on the left hand side. This field provides useful information to the user in charge of starting a new task instance, namely a new activity. Note that you can use the embedded HTML editor to provide rich formatting to this content.

Case Priority: A variable or fixed integer which determines the priority of a task. The priority of a case can be between 1 and 5:

5 Very High

4 High

3 Normal

2 Low

1 Very Low

By default, the priority of cases is determined by a system variable named @@SYS_CASE_PRIORITY, which has a default value of 3 (Normal priority), but that value can be changed by setting the value of @@SYS_CASE_PRIORITY in a trigger (or in a DynaForm field named "SYS_CASE_PRIORITY"). However, the case priority can be determined by a custom case variable. For instance, the case variable @@approvalTaskPriority could be used and its value could be set in a trigger which examines the case data and determines the appropriate value. Likewise, its value could be set in a DynaForm dropdown box named "approvalTaskPriority" which allows the user to select the appropriate priority. If cases at this task should always have a fixed priority, then enter an integer between 1 and 5.

The cases in the Inbox (formerly named TO DO) list are ordered by their priority, so priority 1 cases appear at the top of the list and priority 5 cases appear at the bottom.

Starting Task: Check to make the task the start of the process. A process can have multiple starting tasks.

Task Designation Rules

Although a task can be assigned to multiple users or groups of users, only one user out of the pool of assigned users can be designated to work on a task at a time. Designation rules (which used to be known as Assignment Rules) determine which user from the pool of assigned users is given the authority to work on a task in a case. There are five options for Designation Rules:
Cyclical Assignment, Manual Assignment, Value Based Assignment, Reports To, and Self Service.

Once ProcessMaker designates a user to work on a task in a case, case will appear in the user's Inbox list (formerly named To Do) under the CASES menu. That user will stay the designated user until the task is completed or the case is canceled or deleted.

Note that Designation Rules have no effect on the initial task in a process, because whoever initiates the new case will automatically be designated to work on the first task in the process.

Cyclical Assignment

Cyclical Assignment is the default type of assignment, where the task is assigned in a particular user by selecting that user from the pool of available users in a round-robin manner.

For instance if there are three users named "Sally", "Jane", and "Anne" assigned to a task, then the users will be assigned to cases in the following manner:

ProcessMaker cycles through the pool of available users, assigning each one of them in order, until it has run through the entire pool of users, then it starts the cycle over. This option should assure that all the users get assigned to an equal number of cases, However, ProcessMaker makes no attempt to check the workload of a particular user or how many cases that user has pending. If a user is on vacation and has hundreds of uncompleted cases, ProcessMaker will continue assigning cases to that user.

Manual Assignment

With manual assignment, the user who completes the previous task in the process will manually select the user to work on the next task in the process. After completing the previous task, the user will be presented with a list of all the assigned users to the next task and will be asked to chose one to work on the next task.

Value Based Assignment

Value Based Assignment allows a variable to specify which user will be given authority to work on a task. The variable can be set in the Variable for Value Based Assignment textbox which appears when the option is selected. By default, the variable is @@SYS_NEXT_USER_TO_BE_ASSIGNED, whose value should be set to the UID (Unique ID) of the next user to be assigned to the task.

The value of @SYS_NEXT_USER_TO_BE_ASSIGNED can be set in a trigger, which should be set to fire at some time before task assignment. A custom variable could also be used. For instance, if you want different users to handle a task, depending upon the amount of money involved in the case, you could define a custom variable @@NextUser to enter in the Variable for Value Based Assignment field. For instance, if you have a local manager who handles minor expenditures below $1000 and a regional manager who handles major expenditures over $1000, this trigger code could examine the amount of money involved, and then decide which user handles the task:

if(@@Amount <1000)$NextUsername='annsmith';//the local managerelse$NextUsername='tedjones';//the regional manager#look up the UID for the $NextUsername in ProcessMaker's MySQL database:
$query= executeQuery("select USR_UID from USERS where USR_USERNAME='$NextUsername'");@@NextUser =$query[1]['USR_UID'];

Reassigning a Previous User in the Case

Value Based Assignment can be useful if the same user needs to work on a task repeatedly. For example, imagine a process contains a task where an employee fills out a report. If that report is sent back to the same task for revision, the same employee who initially filled out the report should be assigned to the task again. Set the task to use Value Based Assignment using the case variable @@NextUser. The first time the task is executed the currently logged-in user will be assigned to the task, which can be determined from the system variable@@USER_LOGGED. All subsequent times, the task will still be assigned to the same user. Here is the trigger code which would be fired before task assignment:

if(!isset(@@NextUser))//if @@NextUser does not exist@@NextUser =@@USER_LOGGED;

If the next user to work on the task needs to be randomly assigned from the pool of assigned users, then the following trigger code could be used instead:

//Look up the task UID in the wf_workflow.CONTENT table//To find it, use the following search: SELECT CON_ID FROM CONTENT WHERE CON_CATEGORY='TAS_TITLE'$taskId="XXXXXXXXXXXXXXXXXXXXXXXXXXXX";//if first pass through task:if(!isset(@@NextAssignedUser)){//look up all the assigned users to the the task in the database:$aUsers= executeQuery("SELECT USR_UID FROM TASK_USERS WHERE TAS_UID='$taskId' AND TU_TYPE='1'");//get random number to select the user:$noUser=rand(1,count($aUsers));@@NextAssignedUser =$aUsers[$noUser]['USR_UID'];}

Reports To

The Reports To assignment rule is a new feature available in version 1.6-3862 and later, which takes into account your organization's structure (organigram) as represented by ProcessMaker Departments. It selects the supervisor/manager of the user who completed the previous task in the process to work on the current task. This is a useful option when the process requires that the supervisor review the work of the people in his/her department. If a supervisor for a subdepartment completes the previous task, then Reports To will select the supervisor in the parent department to work on the current task. In this way, tasks can be passed up the chain of command in an organization.

The Reports To assignment rule is useful when a task can be worked on by a large pool of supervisors. For example, a complex organization wants to use the Expense Report Process (which is available for free download from the library), but that organization has 100 employees from 10 different departments who can report the expenses that they incurred on the job.

The problem is there are 100 employees who are assigned to the "Report Expenses" task and 10 different supervisors assigned to the "Approve Report" task. The supervisor of the employee who initially reports the expense should be the person who reviews it and decides whether to approve or disapprove the expense. In order for the correct supervisor to review the expenses from his/her department, use the Reports To assignment rule for the "Approve Expense" task.

Before using a Reports To assignment rule, first go to USERS > DEPARTMENTS and create the departments and subdepartments for your organization. Once the organizational structure is defined, then click on the [Edit] link for each department and click on Assign users to select the users who will be members of that department. Then, select which member will be the Supervisor/Manager for the department. (The supervisor/manager can also be selected for a particular user by going to USERS > USERS LIST, clicking on the Edit link for that user, and selecting from the Reports To dropdown box.)

Make sure that every user assigned to the previous task is a member of a department or has selected a supervisor/manager in the Reports To field in his/her user profile. If the user who worked on the previous task does NOT have a supervisor/manager, then the message "The current user does not have a valid Reports To user." will appear when routing the case.

Self Service

A Self Service assignment rule allows any user from the pool of assigned users to grab the case and work on the task. In other words, the user will have the power to assign himself/herself to the task. Self Service can be used to reduce congestion in the workflow, especially when the users can best judge their capacity to take on new cases.

When a case is routed to a task with a Self Service assignment rule, then the status of the case will be listed as "Unassigned":

The case will then appear in the Unassigned list of cases for all the users who have been assigned to the task.

Any user in the pool of assigned users can examine the case by clicking on View to see the details of the case. To assign himself/herself to work on the case, click on Claim this case.

The case will then be moved to the Inbox of that user to be worked on and will dissappear from the Unassigned list for all other users in the pool of assigned users.

The Credit Card Application process is a good example of how Self Service assignment can be effectively used.

Normally, the "Data Base Update" task is handled by Cyclical assignment, but Self Service assignment is more efficient and productive, because any of the assigned users who is currently working can then enter the credit card application into the database. This avoids untimely delays, because it is no longer necessary to wait until a particular employee comes to work. Furthermore, the employees at work can best judge whether they are free to handle the "Data Base Update" task at any particular time.

Task Timing Controls

This task property is used to control the task due date.
The process and the tasks must be done in determined times, this is why ProcessMaker has this property. With this property it is possible to define duration in terms of time, within a calendar.

There are three options to set:

Task duration: The duration of the task an integer.

Unit time: The unit of the duration it can be hours or days.

Days to enter: The duration of the task, which can be counted in work days or calendar days.

If the time set to complete a task has already passed, the case will be displayed with the "Due Date" in red in the TO DO and DRAFTS tabs under the CASES menu. The red due date will alert the user scanning the list that this case is overdue and needs to be handled promptly.

Timing Control in version 2.0 and later

For this version a new option is available: Allow user defined timing control. This option allows the user assigned for an specific task to define manually the timing control when a case is derivated.

Right click on the Task Properties in which the Timing Control needs to be defined, then go to Properties - Timing Control Tab, and the parameters for the Timing Control will display:

Checking this option, all the options below this will dissapear:

Example

Create a Case with 2 tasks, on the properties of the second task check the option Allow user defined timing control then start the case, when the task 1 is derivated into task 2, below the derivation screen will appear the parameters for the Timing Control:

Task Permissions

This task property will enable Allow arbitrary transfer (Ad hoc) and it will allow the users of the task to transfer it to users chosen in the Users & User Groups (Ad hoc).

As an example to use this property in a task we will enable this property. Then we can create a user in Users & User Groups (Ad hoc). When running the case the user assigned to the task can reassign by clicking in Actions and in the actions menu in Adhoc Assignment, where a dialog with a list of the Users & User Groups (Ad hoc). We can see this in the illustration.

Task Case Labels

By default cases are labeled according to their case number, which can make them difficult to identify when looking at a list of cases. Users scanning the list will not know which cases to work on when they have titles such as "#1", "#2", "#3", etc. The Case Title and Case Description can be customized to provide more better information about the case.

There are two fields for this property:

Case Title: In this field the user can assign names to the cases. In the name we can insert variables. Use the [ @@ ] button to view what variables are available and insert them in the expression.

Case Description: In this field the user can write a description for the case, and it can be as descriptive as needed.

To enable email notifications, when a user is assigned to work on the current task in a case, check the option: After routing notify the next assigned user(s).

Once notifications are enabled, enter the text for the body of the message which will be sent to the next assigned user(s). System and case variables can be inserted into the text. Use the [@#] button to view what variables are available and insert them in the text.

Assigning Users to Tasks

After creating tasks for a process, user(s) and/or user group(s) need to be assigned to those tasks. See Managing Users for more information about creating users and groups.

Assigning Users and User Groups

People who are assigned to a task will be given access to the case and the power to complete the steps in the task. Their access to information about the case can be limited. For managers who want to review cases, it is better to assign them as Supervisors to the case.

A task can be assigned to individual user(s) and/or group(s) of users. If assigned to a group, anyone in that group can complete the task. If more than one user is assigned to a task, the task will be passed between the available users until someone completes it. See Configuring Task Assignment.

Generally it is better to assign tasks to groups rather than individual users, even if there is only one user in the group. The user assignments will be lost whenever a process is exported, but the group assignments aren't lost. After importing a process, it is easier to assign users to groups in ProcessMaker, rather than having to go through all the tasks, manually assigning users. For instance, if your organization has a chief financial officer named Sally Barnes, then create a group called "Chief Financial Officer" and assign Sally Barnes as its member. If the chief financial officer for your organization changes or you need to export all your processes to another server, all you will need to do afterwards is assign a user to the group "Chief Financial Officer", rather than reedit all your processes.

To assign user(s) and/or group(s) to a task, right click on the task in the Process Map and select the option Users & User Groups from the menu. In the dialog box which appears, click the Assign link to open another dialog box which lists the available users and groups. Groups are listed first and show in parenthesis the number of members in the group. To search for a user or group, type part of their name in the Search box and press ENTER. (Note that the search is case insensitive and can not include wildcard characters.) After a search, return to the full list of available users and groups by clearing the Search box and pressing ENTER. Once the desired user or group is found, click on Assign.

Assign Users and User Groups (Ad-hoc)

Ad hoc assignment of users/groups to tasks makes those users/groups available to be reassigned to the task, but these users/groups are not assigned by default to the task when it starts. Ad hoc users can be manually reassigned to the task by users who have the PM_REASSIGNCASE permission in their role and the Process Permissions to open the case.

To assign users or groups to a task on an ad hoc basis, right click on the task and select the option Users & User Groups (Ad hoc) from the menu. Then select which users and/or groups will have ad hoc assignment to the task.

Ad hoc assignment can be useful in a number of situations. For example:

There are temporary or part time employees that are not always available to work on the task, so they should only be assigned to the task when available. A manager or the normally assigned users could reassign the case to the temporary employee when at work.

The workload for employees often changes, so a manager needs to decide which employees are best able to handle the cases. The task is assigned to the manager by default and he/she then looks at the workload and reassigns the case to one on the employees who have ad hoc assignment to the task.

The normally assigned users generally handle the task, but there may be special cases which can only be handled by a manager. Do an ad hoc assignment of the manager to the task and give all the normally assigned users the PM_REASSSIGNCASE permission. When a special case arises, they can reassign the case to the manager to handle it.

Ad hoc assignment can also be used for automatic review of the task by another user after it has been completed by the normally assigned user. Give the task reviewer ad hoc assignment to the task, then right click on the task and select the Task properties option from the dropdown menu. In the "Tasks:" dialog box, under the Permissions tab, mark the Allow arbitrary transfer (Ad hoc) option.

After the normally assigned user completes the task, the case will automatically be reassigned to one of the ad hoc users to review the steps in the task and verify that it was done correctly.

Importing and Exporting Processes

Processes designed in another installation of ProcessMaker can be imported into your installation.

For version 1.X

This procedure will only import the process definition (including DynaForms, Input and Output Documents and triggers) and group accounts, but will not import user accounts, roles, or any cases. If you need to transfer this extra information to your installation of ProcessMaker, see Backing up and Restoring ProcessMaker.

To import a process, go to the PROCESSES tab and click on the Import link at the top of the list of processes. In the dialog box, select a process to import. (Note that process files have a .pm extension).

After importing a process, assign users to tasks in the process and it will be ready to use.

Exporting Processes

To export a process, go to the PROCESSES tab and select the desired process from the list and click its Edit link to open its Process Map. Right click on a blank area in the Process Map and select the option Export Process from the menu. A dialog box will display the title of the process, description of the process, the size of the export file in bytes and a link to the file. Click on the link to download the export file to your computer.

For version 2.0 and later

For this version the procedure import the process definition (including DynaForms, Input and Output Documents, triggers, users accounts and roles).

Importing Processes

To import a process, go to DESIGNER tab, click on Import link at the menu.

In the dialog box, select a process to import. (Note that process files have a .pm extension).

There is another file extension for importing a process .xpdl, this file can be imported only if the process exported has .xpdl extension.

After importing a process, assign users to tasks in the process and it will be ready to use.

Exporting Processes

To export a process, go to the DESIGNER tab and select the desired process from the list and click its Edit link or double-click to open its Process Map. Right click on a blank area in the Process Map and select the option Export Process from the menu. A dialog box will display the title of the process, description of the process, the size of the export file in bytes and a link to the file. Click on the link to download the export file to your computer.

If the file to export is .xpdl make sure to import the file in option.

Activating Debug Mode

When designing a process, it is a good idea to activate the Debug option, which will show you when triggers are fired during routing rules and any errors which occur. In normal production mode, error reporting is suppressed, so it is often difficult to know whether the trigger code executed correctly or not. More importantly, "Debug" mode allows you to examine the values in the variables which are passed to triggers. For security reasons be sure to deactivate "Debug" mode when your process is used in production.

To activate "Debug" mode, right click on a blank area in the Process Map and select the option Edit Process. In the dialog box which appears mark the Debug checkbox and click Save.

Now when triggers fire during a case, a pane containing information about the trigger will be displayed. To examine the code in the trigger, hover the mouse cursor over the name of the trigger.

The variables which are passed to the trigger in an array can also be examined. Click on each variable in the section [Variables involved in the Triggers], to see the values being passed.