This release has some exceptional new functionality provided in OpenProcess Core and these three optionally licensed functions:
- OpenProcess Flex
- OpenProcess - EDMS
- OpenProcess - APIs & RESTful API Steps
As councils are licensed for different options the enhancements are separated into OneVu Core and then the three licensed functions.
OpenProcess Core
In this release we have built the following new functionality:
Notifications on Automatically Completing Steps
In OpenProcess Core you can add Standard and Auto-completing steps. With Standard steps you can add notifications to be sent when the process starts or completes. But until this release you could not do the same with Auto-completing steps.
So, in 2.2, you can now add 'Actions' on this type of step too:
OpenProcess Flex Enhancements
OpenProcess Flex enables organisations to provide more dynamically tailored workflows and crucially more personalised and contextual experiences for your citizens/businesses.
This release adds multiple new features that take this to a new level.
Dynamic Notifications
One of the key elements of OpenProcess is the ability to notify someone when a process moves from step a to step b. Even with OpenProcess core it is possible to send text/facebook messenger messages containing content specific to the step that's just started or completed.
Different options for notifications when a step starts/completes
Static templates for messages
With OpenProcess Flex you can have branches in processes meaning the level of contextualisation in these messages can be taken even further. E.g. if it's a high priority issue send standard message a. If it is medium priority send standard message b when the step completes.
This release takes this functionality further still.
In this release we're providing, in OpenProcess Flex, the means to use the case details present on a process in these notifications. By way of a recap - by case details on a process - we mean the data that is held in the form of 'Fields'. Fields are data items that have been mapped automatically by aform built with eDesigner or manually as a part of a process.
Fields in OpenProcess
Using a new template field function, you are able to personalise the messages that are sent using data held on the case as well as the form reference for the form that they completed if relevant.
To add fields to notifications you need to add the following where the field's code is Field1:
So, if the Field's Code was as follows for a person's mobile number:
Example Field Code in OpenProcess
The format would be:
This is the format for all fields except for the 'Form Reference' as this is actually a process attribute. So to add the form reference to a notification use the following:
Let's have a look at an example. We've built a form called 'Street issues'. The first questions in the form asks about what the nature of their request/report is and where it is:
Street Issues Form - Issue Type Selector
It then asks about them whether they'd like to be kept up to date about it and what the issue is:
Street Issues Form - Person / Issue details
Using the built in eDesigner functionality, the fields in this form have been mapped to the OpenProcess Fields e.g. Mobile Number:
Street Issues Form - Person / Issue details
The process behind it has a branch at the start to automatically go down the correct route based upon the type of issue - for simplicity of visualisation - we've kept the screenshot to three per below:
Street Issue process - with different streams based upon issue type
But importantly, on each of the different 'Reviewing....' steps we've added custom notifications, which include content from the process case fields. For example, this is the email notification setup when the Reviewing Fly Tipping step is started:
Personalised notification with fields in it
In the above, we can see various fields are present, as well as the form reference attribute. So now, if a person completes this form and:
a) Selects Fly Tipping
b) Has a form with reference CPVFWFHG
c) Provided a phone number 07713491749
The following will automatically be generated:
Personalised email notification
This same capability extends to messages sent via messaging services like Notify and Facebook Messenger too:
Personalised messaging via GOV.UK Notify setup
With the following illustrating a GOV.UK Notify delivered text message dynamically populated with the process details:
Personalised GOV.UK delivered SMS notification
The above are just a couple of examples of the use of this.
Emails with form content in the body
This functionality can be used for a huge number of different use cases but can of course be used to send emails to council staff containing the content that matters from the form in the body of the email rather than as an attachment for the first time!
Simply add the action like so:
Back office email notifications with form content in the body of the email
OpenProcess - EDMS
In this release we have added the same template field functionality as covered in Flex above. Namely document templates can now be populated dynamically and automatically with Fields from a process.
This ensures the way in which documents are created is vastly more automated and user error reduced. To help illustrate this consider the following document template, which is a standard document within a corporate complaint process:
Non-dynamic document template
In the above, the person that built the template has added logical areas like <Customer Name> for an officer to replace these with the actual details prior to creating the document.
With the functionality in this version these can largely be dynamically populated properly. We use the same format from earlier:
Again form reference can be added like so:
So you end up with a template, which looks like this and means the letter can be generated entirely from the Field data on the process:
Dynamic document template
OpenProcess - APIs & RESTful API Steps
Case Fields in REST API Body
The first change in this release is a significant advancement for those users using the REST API step functionality.
Essentially, you're able to pass data fields from the process (including data passed from the form as fields obviously) into the JSON payload.
To do this simply check the option indicated below:
New 'Include process fields' feature
When this is set to true you can see the following new section in bold is added to the body of the JSON file output:
{
"SubscriptionId": "30faf4b4-c96d-4b0b-afda-5b321a043000",
"ProcessId": "58155a0f-8a42-4e83-bdd7-d05f8163df7f",
"ExternalReference": null,
"GeoTag": null,
"Documents": [
{
"Name": "Example.docx",
"ContentType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
"Links": [
{
"Rel": "self",
"Href": "/open-api/documents/b8733268-bae0-4e22-9584-47ee7da98915"
}
]
}
],
"Fields": [
{
"Label": "TYPE",
"Code": "TYPE",
"ValueAsString": "Fly Tipping"
},
{
"Label": "KEEPINFORMED",
"Code": "KEEPINFORMED",
"ValueAsString": "2"
},
{
"Label": "FORENAME",
"Code": "FORENAME",
"ValueAsString": "John"
},
{
"Label": "SURNAME",
"Code": "SURNAME",
"ValueAsString": "McMahon"
},
{
"Label": "EMAIL",
"Code": "EMAIL",
"ValueAsString": "john.mcmahon@ieg4.com"
},
{
"Label": "MOBILE NUMBER",
"Code": "MOBILENO",
"ValueAsString": "07713491749"
},
{
"Label": "DETAILS",
"Code": "DETAILS",
"ValueAsString": "Rubbish innit"
}
]
}
This therefore removes the need to get an XML file from eMapper, as you can map the content from the form directly into OpenProcess Fields and thus have them in the body sent to your API.
Supervise Tasks to close failed REST API calls
Recently a help desk call raised identified an issue where if an API call fails for whatever reason there was no ability to then close the process as it was not possible to reassign it to someone.
We've therefore added a new option to mitigate such incidents as shown below:
Release Version Details
The following is the release version info for the version of OpenProcess, which has this functionality.
| Release Date | Version Number |
| 25/06/2021 | 2.2 |