OpenProcess is a powerful and multi-purpose solution providing a huge variety of functions across councils spanning the UK.
For example:
- In Erewash Council, they use it as their corporate EDMS and workflow
- In Wolverhampton Council (and other councils), it delivers 100% automation levels in council tax automation.
- In King's Lynn and West Norfolk Council they have used the REST API step to automate fly-tipping reports into IDOX Uniform and have used the OpenProcess API to automate the completion of process steps and customer updates
- The 3C Digital team (Huntingdonshire, Cambridge City, South Cambs Councils) have used the REST API step to automate updates to Yotta's Alloy service for many services.
- In Trafford, they're using eDesigner and OpenProcess' REST API step to send PPE requests via an API into a database for export and reporting purposes.
- In the councils we have using OneVu, e.g. Lambeth Council it provides a way for citizens to track the progress of their request and provide supporting documents too
The functionality of OpenProcess has been continuously extended to enable councils to work smarter, automate more, and optimise citizen user experiences.
This is a major release and adds some new enhancements as well as a new separately licensed function that enables complex, multi-branch processes; OpenProcess Flex.
General (Standard) enhancements
In this release we have done the following updates:
1) Private Marker - Notes in Search Processes
When a note is marked to be shown to customers, the customer is sent a notification and they can view this in OneVu where OneVu is in use. Where the note is not marked to be visible to the customer a PRIVATE marker is appended to the note when viewing it in My Tasks:
This same marker is now also present when searching for processes:
2) New Process Steps layout
Currently, when you're creating a process the view is as follows:
From this release this will change to look as follows with the only difference being that rather than a large blue button between each step there is now a smaller 'plus' filled icon:
3) Change to process step edit panel
Currently, when you edit a process step all of the information is in the same panel:
As we add more functionality, it makes more sense to group these logically and so there is now a different design with three tabs. The first of the two tabs simply separate out the existing functionality:
Details
Actions
This has the benefit of meaning that existing actions can now be expanded and viewed straight away.
4) British Summer Time
Date time will now show correctly during the months where British Summer Time is in place. I.e. they were previously showing an hour behind owing to using Greenwich Mean Time.
Optional (separately licensed) enhancements
OpenProcess Flex
OpenProcess Flex adds a massive amount of flexibility to OpenProcess processes by providing branching within processes. Process branching is a common feature of workflow solutions, however, the decision points in processes are typically decided by manual user inputs.
With OpenProcess Flex decisions in process branches can be:
- driven by user input
- AND
- automatically by driven by content from online forms built with eDesigner
Product Videos - Watch here
What does this mean in practice?
Let's say you have a form, which needs to managed by 10 different teams e.g. Contact Us.
With OpenProcess Flex you can automatically push the task to the relevant team based upon a drop-down option in a Contact Us form that you've built. You can even decide which team/user should be assigned it based upon a combination of different answers in a form.
Plus, you can make it so subsequent steps in the above process also have a branch that is decided by online form content.
Or it could be moved down a different branch/process route based upon a user-made decision.
Also let's say you have a branch in your process, where each branch has 2 possible stages meaning there are 4 possible stages. With OpenProcess Flex you can send different, highly context-sensitive messages to citizens based upon the stage in question.
I.e. with linear processes sometimes automated emails require to be relatively generic. But with the ability to have context-sensitive notifications sent to customers for each of the 4 stages, messages can be personalised to the customer's circumstances and optimised for the use case specifics.
Finally, where OpenProcess Flex becomes incredibly powerful is when one also adds into the mix that API calls can be made at any stage in a branched process. So if you have the same 2 branch process, where each branch has 2 possible stages and each stage is a REST API stage, you technically have the means to send 4 different API calls to 4 different systems. Whilst in practice it will more likely be 4 different API calls to 1 or 2 systems, the point is that it is possible to deliver very intelligent automation that driven automatically by the content from the form.
In summary, OpenProcess Flex provides a massive leap forward in terms of automated work routing, the flexibility of process, and personalisation of customer messaging.
We will walk through each of the functions and then show a worked example to help illustrate how to use the functionality.
Functionality
New Field Type - Choice
In an earlier release, we added the ability to set Fields associated with a process. For example, a field type could the geolocation of an issue reported.
There were two options before:
- Single line of text
- Geographic Location
There is now a field type Choice as shown below:
This field type, which provides support for many useful things. For example:
- To provide a list of completed reasons
- To provide a list of canceled/abandoned reasons
- To act as a checklist of things a person needs to do for a step
- To trigger a branch in a process
Make a field (or fields) mandatory as a part of a step
It is now possible to make it so fields have to be provided prior to completing a step. You can see an example of this below where the officer needs to set whether prosecution is being saught and some notes:
Now when a person attempts to complete this step they see this if they attempt to complete it without providing the mandatory information:
I.e. the warnings go away if the user provides responses:
Each and every step can have mandatory fields associated with the steps. Ensuring your workflows are completed in a standardised manner.
Branches
The most obvious distinction when building a process is the presence of a new option to add a 'Branch':
When one has added a branch this appears initially as follows:
Essentially, a single condition/decision point is added.
Before a process with a branch can be saved it needs a name AND a condition. If neither is added the following will be presented when attempting to save the process:
To add a name and condition to a branch you need to click on the pencil icon in the top right of the box which says IF condition. When you do you will be presented with this:
Each branch or condition needs to have a name and a rule (condition) to drive it. The name is best to be something easily understood by a layperson i.e. High Priority Fly Tip Removal is pretty clear that this is the high priority branch:
The condition itself requires one to understand the syntax (format of the content) to be used. So this condition will be true and this branch followed if the field IMPORTANCE is equal to HIGH. If we look at the Field for Importance we can see where this has come from:
It has been set as Choice Field type. Where the 'Code' is 'IMPORTANCE' and the 'Value' is 'HIGH'. These two elements are used to indicate the field type and the specific option within this field type.
IMPORTANT
It is important to note that Choice field types are for decisions that will be made by users. I.e. if you want to meet a condition with a Choice field type then it will need to be a mandatory field that is answered when completing a step.
Data from an online form, even if it was a choice/list in a form you've built will always end up being a single value for the purposes of the back office. E.g. in the example below the field OFFENSIVE has come from a Yes/No answer to the question "Do you find the graffiti offensive?":
It is a single line of text because a user is not setting this. It has already been decided by the customer's choice in the online form i.e. Yes or No.
To add another condition simply click on the icon with the branch icon shown below:
The following illustrates three branches in a process:
Note that a branch is not a step. A branch is simply a means of creating separation in a process. Notice that in each branch there is a 'Plus' icon. Clicking this will then allow one to set the step type desired:
This means that you could have different steps against high, medium, low that have different SLAs, are handled by different teams, have different emails issued when the step is started/completed etc.
Below, one can see an example of a process where there are two branches and the first branch has two steps. The second branch has just one step:
One can also see that there is a 'Bin' icon against both steps and branches. It is possible therefore both to remove individual steps as well as branches. Deleting a branch will delete all steps within it.
Therefore if you attempt to delete a branch/step you will see the following:
Nested Branches
Not only can you have branches you can have branches inside branches. To illustrate, here is a very complex branching process:
There are branches for where the graffiti is offensive, over 2m high, where the council is deemed responsible and where a cherry picker has/has not been arranged. So even the most complex of processes can be handled with this functionality.
Multiple Conditions
In the above process the first step is reached if three conditions are met:
1) It's on public land
2) It's offensive
3) It's over 2 metres high
Now for visual purposes and to illustrate nested branches there are separate branches for all three of these. I.e. On each branch there are these three conditions:
1) Fields["PrivateLand"] == "No"
2) Fields["OFFENSIVE"] == "Yes"
3) Fields["HIGH"] == "Yes"
But it does not have to be designed like this. You could have a single branch with the name Public > Offensive > High. And the condition you would set would joint all of these. The way to do this is to place this between the conditions:
&&
This is the same as AND. So:
Fields["PrivateLand"] == "No" && Fields["OFFENSIVE"] == "Yes" && Fields["HIGH"] == "Yes"
Adding a condition like this is logical because all three pieces of data are captured in an online form and shortens the scale of the process diagram potentially.
You can also do things like this:
Fields["PrivateLand"] == "No" || Fields["OFFENSIVE"] == "Yes"
Where two 'pipes' i.e. || mean OR. I.e. if the customer answers private land: No OR Offensive: Yes the same condition would be met.
And you can also use a NOT operator which is an exclamation mark e.g.
!Fields["OFFENSIVE"] == "Yes"
Means anything other than Yes will lead to the condition being true.
Important
The field names and the content referenced in conditions is all case sensitive. So if the field name is:
OFFENSIVE and you use Offensive it will not work.
Advanced use cases
You can also use mathematical operators like:
int.Parse(Fields["Amount"]) < 2
And where it is a monetary or decimal value
decimal.Parse(Fields["Amount"]) > 100.00
decimal.Parse(Fields["Amount"]) < 100.00
decimal.Parse(Fields["Amount"]) == 100.00
You might use the above for example with a payment arrangement/debt management based online form/process. Sending it to a different officer dependant upon whether they are more than a certain amount in debt.
And finally, you can compare fields with one another E.g.
Fields["BalanceThisYear"] < Fields["BalanceLastYear"]
To determine the branch in which to trigger.
General rules on conditions
- When the process reaches a branch step, the process engine will start the first step on the first conditional branch, where the condition on the branch evaluates to true (i.e. the condition you have set is met)
- When the process reaches a branch step, in the event that none of the conditions on the branch evaluate to true, the preceding step will not complete and an error will be raised
- If the branch step is the first step in a process, and none of the conditions on the branch evaluate to true, an exception will be raised and the process will not be created.
So if a form is submitted and does not have the data needed to meet one of the conditions that will start a process it will not create the process and an integration failure will show against the form itself within the Forms Portal as shown below:
To prevent this it is therefore important to ensure that if the first step of a process is a branch needing some data that this is mandatory in your online form.
New Allocation Rule
Whilst each stage of a process can be assigned to a different user or team, there are often use cases where the same user will deal with the whole process or multiple stages of a process.
Right now there is an allocation strategy (rule) that does this called 'Allocate to user from defined previous step'. In this case, the user specifies the step which was previously allocated to a user to set who should be allocated this step:
The problem is, with a branched process some previous steps may not ever be completed because the branch rules mean they're not active in the process. Let's consider the following branched process:
If it worked as it does now and you were setting the assignment rule for the final two steps you could technically pick any of possible previous blue steps even though the path to get to the end step may not have touched them. To remedy this, the new allocation rule is called "Allocate to the same user as the step before" as seen below:
IMPORTANT
1) Where there is a branch in a process you need to use this allocation strategy. If you attempt to use:
'Allocate to user from defined previous step' on a process with a branch in it you will be unable to select a step.
2) If you try and save a process, which has a branch, and a step allocation rule set to 'Allocate to user from defined previous step', you will face this error:
3) If you make the first stage of a process have the allocation strategy of "Allocate to the same user as the step before" the process will error upon creation so you should NOT do this.
Search Process - Steps View
When you search for a process you will normally see the steps as seen below:
With a process that has branches you can still see the steps completed but you can ALSO see any branches. E.g. the process below is currently on the first step and three decisions were made to get to the active step in place:
And illustrates the different elements that were added to make this process.
I.e. whilst this process has a variety of sections/branches it is actually just the same functions above replicated for each of the different conditions.
We think this functionality is going to be a game-changer for councils in terms of efficiency, intelligent routing of work and personalisation of proactive messaging.
We hope you agree and can't wait to hear how you use it.