In its simplest form a process consists of something that needs to be done, where zero or more conditions need to be met before the process can be started. For example, the following analogy describes the process of making a cup of coffee:
The process follows a logical sequence of tasks, but the process could involve a level of complexity (see below) in that some cannot be
completed until certain conditions are met. I cannot boil the kettle until I've filled it and I cannot add coffee, sugar, milk, or water until I've got a mug. Similarly I cannot realistically stir the coffee before doing the previous processes either. That said, I could choose to do process 2.4 before process 2.2—they don't necessarily need to be run in a particular order.
We can see above that there are conditions on whether a process can be started. In this example these conditions are fairly simple; in a real world
CHAPTER PART 9: PROCESSES
order in which they need to be done (either parallel or sequential) and conditions on those processes being available to do. The Purchase process could be broken down into the following stages and each one would be an individual process. When the workflow activities required to complete a stage are completed, the next is started. If a process contains sub-processes, then these must be completed in order to proceed.
1. Purchase
2. Take Instructions 3. Searches
4. Pre-exchange
4.1. Draft Contract Received 4.2. Raise Enquiries
4.3. Check Mortgage Offer 4.4. Report On Title To Client 4.5. Pre-exchange Checks
4.6. Completion Statement And Bill 5. Exchange
6. Pre-completion
For each of the process states it is also possible to execute a workflow when the state changes. This allows you to assign an action to any part of the process life cycle. For example, it might be desirable to post the amount of time spent producing a letter to a house buyer when their purchase has completed. These workflows are independent of the process workflow, and run purely on state changes. See Attach workflow to a process.
So, to sum up, processes can be used to define long running business flows. They allow you to break down everything that needs to be done and map out all the stages involved, however complex. A process can contain any number of sub-processes, conditions, and at each level a workflow can be executed. In Designer Studio you create processes in Process Designer.
In this section:
• Process Designer
• Process state
• Conditions
Process Designer
Process Designer is a tabbed pane that allows you to manage a long running business process, e.g. Purchase. When you open a process you are opening an instance of the Process Designer and you will automatically see a contextual tab in the ribbon bar that shows options specifically related to processes.
Process Designer is split into 3 panes—the Process pane, the Properties pane and the Pre-conditions pane.
Fig. Process Designer
A. Process pane B. Properties pane C. Pre-conditions pane
• Process Designer is only displayed when you open a master process.
Process states
CHAPTER PART 9: PROCESSES
Fig. Process diagram
A process starts in a Standby state and must be activated before it can be used. Once activated, a process moves to a Pending state. It transitions to Ready once all pre-conditions have been met, In Progress (either manually by you choosing to run a process or automatically when set to auto-run), and then Completed.
Between the Pending and Ready states there are optional pre-conditions as shown in (A). These conditions determine whether the process can transition to Ready. If a process has no pre-conditions, then it can transition directly to Ready. The process transitions (B) directly to Completed. Also, a process will go straight from Pending to Completed if an override condition is met (C) before its pre-conditions.
The process states above outline the states that a process can be in. The table below explains how these states are reached.
Process States
initialised too. Pre-conditions record audit information about when they started and were met.
Waiting When a process is waiting for its immediate parent process to start, it is set to this state.
Ready When the pre-conditions for a process have been met, that process moves to the Ready state. Processes may be manual or automated, so for manual processes you will click on an icon to run the process. Automated processes will transition from Ready to In Progress with no user input.
To achieve this, the Auto-run flag must be set against a process; this indicates that the process should transition from Pending, through Ready, to In Progress
automatically once all pre-conditions have been satisfied.
Note: There is an implicit pre-condition on every process that the immediate parent process must be In Progress.
In Progress Any process that has been manually started by you or automatically started by the system is marked as In Progress. Some processes will be completely
automated—in this case a workflow will be assigned to the process. When this is the case, the process will be moved from In Progress to Complete when the workflow has finished.
Completed This state is the most complex and is dependent on several factors. The options fall into the following categories:
A process with no sub-processes
If a process is created and it has no sub-processes then it won't transition to Completed, other than by you specifically choosing to complete the process from the user interface. However, if the process includes a workflow, when the workflow completes the process state will automatically transition to Completed.
A process with sub-processes
If you have (say) two sub-processes attached to a process, the process's lifetime will, by default, be dependent on the processes. When the last
sub-CHAPTER PART 9: PROCESSES
You can use logical operators to combine Completed sub-processes to the Completed value of the process. You might have an optional process—so you could have a process where sub-processes A and B are mandatory, but sub-process C is optional. You can then use override conditions to deal with this.
Conditions
A condition is, in its simplest form, a function that returns a True or False value. In processes, they are used to control the things that must be met before a process can be run (pre-condition).
A condition needs to be evaluated, so there may be some run-time context that is passed to the condition so that it can be evaluated. A condition could be one based on the value of a field. For example, you could have a condition such as "Is Legal Aid matter?" which could be computed at run-time, but could also be computed just once (when the matter is created), assuming that the field is static for the life of the matter. This is a "static"
condition that changes rarely. Once met it remains met unless the process is reset. See Add pre-conditions to a process.
NOTE
• Users with the relevant permissions can manually complete a process even if the pre-conditions have not been met.
Create a master process
You can create a process to map out the stages in a business process. You start by creating the top-level process, called a master process, and then adding the desired sub-processes for each of the different stages. For example, the Purchase process would have a master process called Purchase and sub-processes for all its stages, e.g. Take Instructions, Pre-exchange, etc. A master process can contain any number of
sub-2. From the drop-down menu, click Master Process.
3. When the Properties pane opens, complete the following:
• Name. Specifies a name for the master process.
• Description. Specifies a brief description of the master process.
• Auto-run. Specifies that the process will run automatically.
• Entity. Specifies the owning entity.
4. Click Design. Process Designer opens ready for you to build your process. You can set the following options:
• User role. Specifies that a user with the selected role in relation to the matter (e.g. Matter Supervisor) will be automatically assigned any tasks that are created by the process or the workflow
associated with the same process. Defaults to Matter Fee Earner.
• Automatically transfer tasks to runtime user. When the process runs against an enquiry all tasks are assigned to the run-time user. When this process becomes available to run as a
consequence of running earlier processes, this option specifies that its tasks will automatically transfer ownership and run for the currently logged in user, regardless of the user they are initially assigned to.
• Due date. Specifies a due date for any tasks created by the process or the workflow associated with the same process. This is the result of a formula. When left empty the task will be due on the date the process became Ready.
• Date can be modified. Specifies that the process due date can be modified at run-time.
• Auto-run process. The process automatically moves to In
progress when it is Ready. When this option is switched off, a task is created for the user to start the process.
• Override condition. Specifies a condition that if met before the pre-condition is met, then the process is overridden and does not run. Where this is the case, the Process Overview shows a blue tick to indicate that it is not required. See Process override conditions.
5. Next, you can:
• Add sub-processes
• Add pre-conditions
• Add operators
CHAPTER PART 9: PROCESSES
NOTES
• When there are a succession of tasks for the same process (e.g. the associated workflow has multiple attended activities) and another user takes ownership of a task:
o All the tasks for the same process go to the new owner.
o All tasks are assigned the same due date (the formula is not re-evaluated for each task).
Add a sub-process
A stage in a process may require that a number of other activities are performed before the process can be deemed complete and the process can move to the next stage. As previously mentioned, it is therefore possible to create any number of sub-processes within a process. Use this procedure to add a process within a process.
To add a sub-process:
1. In Process Designer, select the process to which you want to add a sub-process.
2. On the Process tab, click Add Process.
3. When the Additional Information pane opens, complete the following details:
• Name. Specifies a name for the sub-process.
• Description. Specifies a brief description of the sub-process.
• Workflow. Only available when a process does not have a sub-process. Specifies the contact- or matter-level workflow to run when the sub-process is reached. Select Contact or Matter from the drop-down and then choose the desired started. You can also click the Plus sign to create a new workflow. NOTE the workflow is not automatically selected. Clicking the Edit button opens the
associated workflow.
• Role type. Only available when the Workflow option is set to
contact process. A process completed condition is attached to each duplicated process to ensure they run one after the other.
• Auto-run process. The process automatically moves to In
progress when it is Ready. When this option is switched off, a task is created for the user to start the process.
• User role. Specifies that a user with the selected role in relation to the matter (e.g. Matter Supervisor) will be automatically assigned any tasks that are created by the process or the workflow
associated with the same process. Defaults to Matter Fee Earner.
• Automatically transfer tasks to runtime user. When the process runs against an enquiry all tasks are assigned to the run-time user. When this process becomes available to run as a
consequence of running earlier processes, this option specifies that its tasks will automatically transfer ownership and run for the currently logged in user, regardless of the user they are initially assigned to.
• Due date. Specifies a due date for any tasks created by the process or the workflow associated with the same process. This is the result of a formula. When left empty the task will be due on the date the process became Ready.
• Date can be modified. The due date can be modified in the task list, e.g. to defer a process.
• Override condition. Specifies a condition that if met before the pre-condition is met, then the process is overridden and does not run. Where this is the case, the Process Overview shows a blue tick to indicate that it is not required. See Process override conditions.
• Label. Only visible when you've specified an override condition.
Specifies a friendly description that is displayed for the override condition at run-time.
4. Click Save.
NOTES
• There is no limit to the number of levels you can create with sub-processes. For example, sub-processes can also have sub-processes attached, and those sub-processes can have their own sub-processes too.
• When there are a succession of tasks for the same process (e.g. the associated workflow has multiple attended activities) and another user takes ownership of a task:
o All the tasks for the same process go to the new owner.
o All tasks are assigned the same due date (the formula is not
re-CHAPTER PART 9: PROCESSES
Attach workflow to a process
When building a process, you can specify that workflow logic should be run when the sub-process is reached.
To attach workflow to a process:
1. In Process Designer, select the parent process.
2. In the Workflow drop-down, select the desired workflow or click the Plus sign to add one.
3. Click Save.
Add pre-conditions to a process
Each process can have a number of conditions associated with them.
These are used to control what must be met before a process can be run.
For example, in the Purchase process the Pre-exchange process must have completed before the Exchange process can start.
To add a process complete condition:
Use this procedure to specify that a process cannot run until a previous process has completed.
1. Select the Pre-conditions pane by clicking the header.
2. On the Process tab, click Add Condition and from the drop-down menu click Process Complete Condition.
3. Next, click the Plus symbol to add a process to this condition.
4. When the Select Process dialog box opens, locate the desired process and click OK.
To add a field value condition:
Use this procedure to specify that a process cannot run until a field value has been met. This can be added as either a pre- or post-condition.
1. Select the Pre-conditions pane by clicking the header.
2. On the Process tab, click Add Condition and from the drop-down menu click Field Value Condition.
3. Next, click the Plus symbol to add a formula to this condition.
4. When the Formula Builder opens, construct the desired formula and click OK.
• To remove the condition, click the Delete button.
• To change the condition, click the Edit button.
5. (Optional) You can also specify a friendly description that is displayed for the field value condition in the Process Overview at run-time. To do this, just overtype "Field Value Condition".
Add operators to a process
You can use operators in your processes to perform basic logical operations. At the time of writing this is limited to the AND and OR operators.
To add an AND operator to a condition:
Use this procedure when you want to specify all conditions listed must be met, i.e. A, B and C must be TRUE. This can be added as a pre-condition.
1. Select the Pre-conditions pane by clicking the header.
2. On the Process tab, click Add Operator and from the drop-down menu click AND Operator.
3. Click on the Add Condition, select and create the required condition.
CHAPTER PART 9: PROCESSES
The Conditions display indented below the AND Condition as below:
To add an OR operator to a condition:
Use this procedure when you want to specify that only one of the list of conditions need to be met, i.e. A or B or C must be TRUE. This can be added as a pre-condition.
1. Select the Pre-conditions pane by clicking the header.
2. On the Process tab, click Add Operator and from the drop-down menu click OR Operator.
3. Click on the OR Condition, select and create the required condition.
4. Select the OR Operator, click the Add Condition and create the second required condition.
5. Repeat for step 4 for the number of conditions required.
The Conditions display indented below the OR Condition as below:
Process override conditions
When creating a process it is possible to specify an override condition. This allows you to instruct a process to ignore a pre-condition if the override condition is met. For example, if a process that captures estate agent details is set up with a pre-condition that requires an estate agent to be instructed, then an override condition may be set up so that if an estate agent has not been instructed, the process is skipped.
Override conditions are the result of a formula, so in the case of the example above, a process called Capture estate agent details would have an override condition of "Estate agent instructed = No", which when the Estate agent instructed field was set to No the override condition would be triggered and the process skipped.
A description can also be specified for an override condition, e.g. Not required when an estate agent has not been instructed. This is displayed in the Process Overview to show a friendly explanation of the override condition.
When an override condition is met, the usual green tick (that shows against completed processes in the Process Overview) is replaced with a blue one to indicate that the override condition has been met instead.
NOTES
• A process without an override condition cannot be overridden.
• When an override condition is met at the same time as a pre-condition, the override condition wins.
• When a process completes due to an override condition being met, its parent process is checked to see if it can also be completed.
Due date override
When creating a process it is possible to specify that the Due Date of any associated tasks can be modified by the case operator. Whilst it is always possible for case operators to run tasks early regardless of this setting, this option allows case operators to manage their workload by deferring tasks that have dates that are not set in stone.
In the process overview window, where a Due Date has been set to be
CHAPTER PART 9: PROCESSES
To allow a Due Date Override:
1. In the Process details screen, check the Can be modified check box to the right of the Due Date field.
NOTE
• It is only possible for case operators to override due dates on their own tasks
• A record of the change is stored in the process history
• Where a Due Date is changed, it is for that process only
Change the process hierarchy
Use this procedure to move a process or a condition up or down in the
Use this procedure to move a process or a condition up or down in the