Cases Functionality

In OpenProcess “Cases” can be used to group linked processes, documents and notes into a single unit. The benefit of this is that when a user is looking at a Case they will be able to see all case-level Fields, Notes and Documents that have been recorded across multiple sub-processes linked to the case, rather than only being able to see those details against each individual process.

The “Cases” functionality enables:

- Case Milestones to be configured

- A sub-process to be started from a step in a process (and then either wait for sub-process to be completed, or carry on in parallel)

- Multiple parallel sub-processes to be started from a process

- Case-level fields to be defined (which can be used in process branch decision points and document/email mail merge)

- The creation of mail merge Document Templates, and auto-generated emails on process step start/complete, using process-level and/or case-level fields

- A case-level field to be date stamped when a step completes

- A Case Officer to be assigned to a case

- A case to be started when an eDesigner form is submitted

OpenProcess – Process Setup

When creating/editing a process in OpenProcess setup you are able to link more than one process together to enable:

- A sub-process to be started from a step in a process (and then either wait for sub-process to be completed, or carry on in parallel)

- Multiple parallel sub-processes to be started from a process

You may want a new process to be started when the end of a process is reached, which will enable multiple sub-processes to be linked together. Alternatively, you may want a sub-process to be started and run in parallel to the ongoing process.

When adding a step to a process there are two additional options:

· Add a sub process step

· Add a parallel sub processess step

Add a sub process step:

You give the step a name and a description and then you can select the process you want to be started from the drop-down list.

You can then set whether the current process should “wait for sub-process to complete” before the next step is generated or not. This allows for scenarios where you may want the whole of the sub-process to be completed before the next steps of the current process are triggered.

You can also control whether the system should “override allocation of the first step of each sub-process to the same user as completed the last step in this process”. This could be used in scenarios where you want the same user to continue to work on the case as they would then be allocated the first step in the linked sub-process.

Case Setup

When creating the Case Type you can select which processes make up that type of case:

Case-level Fields

Fields can be added to a Case Type, so they act as case-level fields instead of process-level fields. The benefit of this is that when a user is looking at a Case they will be able to see all case-level fields that have been recorded across multiple processes linked to the case, rather than only being able to see fields at each individual process-level.

When configuring a process step( in setup), fields that are mandatory to complete the step can also include case-level fields:

Please note:

When a case is started from an eDesigner form, if the incoming field code matches against a case level field code, the field is stored against the case. Otherwise it is stored against the process that is started as part of creating the case.

If your process is using fields that are part of case, but the process is launched outside of a case then it won't work. The branch evaluations will fail for any condition using case field. Evaluation won't result in an error but value of field would be 'null'

When setting up fields that 'are needed to complete this step'. This will allow you to select case-level fields from all the case types the process is linked to. Linking a process type to more than one case type will add complexity for the person designing the case/process. We would recommend not sharing processes between case types.

Case-level fields can then be created:

Milestones can be created:

When adding a milestone group you need to choose which process will be the start of the milestone and then you can give the milestone a name and set when a warning should be given and the target date (due after). You then select the process and the process step that will complete the milestone:

Viewing a Case

Case Milestones can be viewed:

The Timeline tab displays all activity across all processes linked to the Case:

The Accounts tab displays the OneVu account the Case is linked to:

The Processes tab displays all processes linked to the Case:

The Fields tab on the Cases screen displays case-level fields (please note this does not display process-level fields). The benefit of this is that when a user is looking at a Case they will be able to see all case-level fields that have been recorded across multiple processes linked to the case, rather than only being able to see fields at each individual process-level.

The Notes tab shows all Notes recorded against all processes linked to the Case. The benefit of this is that when a user is looking at a Case they will be able to see all Notes that have been recorded across multiple processes linked to the case, rather than only being able to see Notes at each individual process-level.

The Documents tab shows all documents linked to the Case. The benefit of this is that when a user is looking at a Case they will be able to see all Documents that have been recorded across multiple processes linked to the case, rather than only being able to see Documents at each individual process-level.

Placeholders for Document Templates

We have added a couple of new placeholders for Document Templates, for case fields and case reference:

{% CaseFieldValue Code="AppField1" %}

{% CaseAttribute Name="Reference" %}