OpenProcess Flex

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:

OneVu - Track my Requests

When a process has branches in it, it becomes impossible to know:

a) which steps will be involved in a process and 

b) what the overall target is for a process.

For example, you could have a branch that results in four different steps being possible, and each of those having a different SLA. To counter this where a process has a branch in it ONLY:

• the current active stage and completed stages will be shown and
• the current active stage's target will be shown.

I.e. all possible stages are not shown only those that are relevant so far. In the scenario below:

• a completed step is shown with its completed date and
• the currently active step has a target showing against the individual step.

But an overall target is not present because it is impossible to know what it is.

Worked Examples

This section will walk through some example processes starting with the most simple and building up to more complex. The examples used are simply indicative of use cases. The actual use cases can be for any service you provide both externally to citizens and internally for staff e.g. HR processes. 

Example One

Let's say you have a linear process like this for 'Report a Pothole':

The process as it stands means that irrespective of the size of the pothole or its priority the issue will always be passed to the same team and have the same SLA. But what if, having reviewed the details provided you could decide whether an inspection was required and thus treat small potholes differently from big ones. If we click on the plus symbol below 'Reviewing the details' step we can add a branch:

When you do this you will see your first condition. We need to give this a name and also add a condition. Before we can do this we need to create the options for the condition. We do this using the 'Fields' tab:

Let's say we want three conditions around High, Medium, Low priority we can see the choices for these below:

When you first add a branch it appears like this. 

Clicking the purple 'branch' icon a further two times means we end up with three placeholders for our conditions:

Now we need to add the condition for each. The condition for each based upon what we learned about conditions earlier will be:

Fields["PRIORITY"] == "Low"

Fields["PRIORITY"] == "Medium"

Fields["PRIORITY"] == "High"

E.g. the low one named and the condition added as follows:

With all three added we see this:

Now, before we add steps to the 'branches' in the process we need to make it so the user needs to set a choice as a part of completing the first step. We do this by clicking the edit icon on the 'Reviewing the details' step, clicking on the 'Fields' tab and selecting the Priority choice as being mandatory to complete the step:

Doing this ensures that the priority is always known and it thus knows which branch of the process to go down. It should look like this when added:

Now when a user completes this step they will see this:

All that is left to do now is set the steps you want within each branch:

As we can see there are four steps and, in this case, all are specific to the branches they are linked to. These have their own SLAs, assigned to their own users and emails sent to the customer. 

Note

If there is a common step that will exist below all branches then you would add it at the bottom below the branch rather than adding it three times i.e. once in each branch. In the above scenario, a different end step is relevant for each branch. 

Example Two

We will walk through an example online form built with eDesigner and a process with branches that are linked to it. 

The process is that of reporting graffiti. Our online form is going to capture:

• Customer details (if they want to provide them)
• The location of the incident
• Whether the graffiti is on private/public land
• If it is on private land, whether the person reporting it is the owner of the private land and whether they agree for council staff to come to deal with it and recharge them
• Whether it is offensive graffiti
• Whether it is above head height (2 metres)
• A description of the issue and
• Any photo uploads

The process underpinning graffiti is surprisingly complicated. The process looks something like this where green lines mean yes / red lines mean no:

I.e. there are a huge number of branches in the process. To remove some of the complexity of the process only the key steps are shown in gray. 

Top tips - when building a very complex process

1) it is best to design the process on paper/some other medium to iron out exactly how you want to do it before you do it. It's easy to create a process with many layers depth and then realise that a decision made in the middle of a process with lots of stages/branches linked to it below needs to be at the top but the stages need to stay where they are. Meaning you effectively need to delete this section and place things where you want them.

 2) Save often - you don't want your session to expire etc. and lose lots of work. 

With a linear process without conditionality the best you could have would be something like:

1) Review report

2) Assigning to contractor

3) Graffiti removed

With OpenProcess Flex it is possible to achieve the process in the same way as shown in the diagram above. 

So the optimum order in which to do this is to:

a) Build your form

b) Build your process 

c) Link your process to the form by adding an OpenProcess Action to the form

The following is our form and we can see the user has set the location of the graffiti and answered the first choice question about whether the graffiti is on private land:

If you're unsure of how to add maps/link to process fields see here.

Field Ids and process branches

If we look back at the intended process we can see there is a branch if the graffiti is on private land or not. 

Let's have a look at how this specific question has been set up. When you are building your form and you have a field that is going to drive a choice within a branch of your process you need to ensure:

a) That you check the 'Map to a key information field in OpenProcess' checkbox

b) You make a note of the Field id you give to this, as this will be needed in the set up of the process. I typically use the same field id for this as that already held on the question itself. E.g. in the below PrivateLand is the field id for the OpenProcess mapping and the question itself. 

Note that in this question there are two options Yes and No. When the user has selected one of these the answer is effectively a single string of text "Yes" or "No". 

The reason this is important is that when you're creating your process you will not use the field type of 'Choice' but instead 'Single line of text'. That might seem confusing but the Choice type is where a council officer is making a choice that determines a branch. In this case, the choice is being made automatically. 

So if we look at the process created for the above form we can see it has all of these fields:

If we click on the 'Private Land' field you can see the following:

Notice that:

1) The 'Code' mirrors the Field Id set within the online form 'PrivateLand' - it is CRITICAL that your code here matches the Field Id set in the form. 

2) 'Single line of text' is the type because the form will pass Yes or No as a single text field

3) This information is required to start the process because 'Required at startup' is set to true. It is, therefore, CRITICAL that any data required at startup is a mandatory question in the online form or the process will not be created where this data has not been provided. 

So for each of the pieces of data from the form that will drive the process they need to be set up like the above. E.g. Offensive and Over 2m are also collected in the form:

In summary, content from your form that should trigger a branch in a process needs to have a field associated with it in your process. 

Where you need decisions to be made in a process that users will make manually you need to add these as choice fields. For example:

• Council is responsible
• Cherry Picker Available

Are two decisions that council staff need to make - the following illustrates the latter: 

Clearly, this is not required at startup and the options are Yes/No. 

The process itself

Using the add branching function documented earlier, the above process diagram has been mirrored into OpenProcess:

We have added branches/decision points as follows with the order in which the branches are check shown below. 

1st level - Public Land / Private Land

2nd level - Offensive / In Offensive

3rd level - Over 2m / Under 2m 

4th level - Council Responsibility / Not Council Responsibility 

5th level - Cherry Picker Booked / Awaiting Cherry Picker Availability

I.e. The Offensive check is nested within and thus checked after the check on whether it is on Private Land.

Now, given this is a complex process we are best to look at a specific branch.

So where it is on Public Land, Offensive, and Over 2m the first step in the process will be:

'Priority- Offensive - High'

If we look at the conditions against the Public Land, Offensive Graffiti, Over 2m we can see three conditions need to be met to get to this step:

Fields["PrivateLand"] == "No"

Fields["OFFENSIVE"] == "Yes"

Fields["HIGH"] == "Yes"

As each of these three decisions are driven by data from the online form, working out the first step happens automatically.

After the first step, Priority- Offensive - High, two decisions need to be made to work out the next step to work out if the Graffiti Removal Organised step should be moved to. These are:

a) Is the Council responsible?

b) Has a Cherry Picker been arranged?

As both of these need a human decision, there are two mandatory fields that need to be set in order to complete the process:

So, when the user attempts to complete this process step they see this:

As a result of the fact that they said that a Cherry Picker has not been booked, it has been pushed to the step from the above process relevant for this 'Awaiting High Access Vehicle Availability':

As well as being able to use fields to drive process decisions fields can be used to record information that's required e.g. when the graffiti is removed the council might want a contractor to record:

• Chemicals Used
• Time Taken
• That a photo has been uploaded showing the graffiti has been removed

This is illustrated below:

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.