Worked Example - Advanced

In this example, 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

Top tips - when building a complex process

1) it is best to design the process on paper/some other medium like Miro or Mural 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.

The Process

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

Process to build

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.

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 process

b) Build your form

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

The eDesigner 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:

eDesigner form to capture the reported graffiti

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.

Mapping content to the equivalent key field in eDesigner

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:

Fields present in our process

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

Example Field

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.

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:

A choice an officer will need to make to drive a branch

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

The process in Flex

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

Multi-faceted hugely nested process

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'

A nested branch for High Priority Graffiti

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:

Adding the mandatory fields

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

Mandatory fields in situ

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.