One of the joys of working in product management is solving problems; particularly tricky ones. The challenge presented to us by the Digital Manager at 3C Shared Services*, Joe Bedingfield, was to enable his team to be able to:

• Build any online service
• Map the content entered by a citizen into XML format
• Post the data to an API to update a back-office application
• Create a trackable online process
• Provide a means to automatically update the customer when notes are added
• Provide a means to automatically update the customer updates made in the back office

If this could be achieved in product it would provide the means for non-technical users to deliver this for any of their digital services in a reusable manner.

Building a cook book

Essentially, we would be providing a recipe to deliver low code end to end digital processes. Fortuitously, we already had some of the ingredients for this recipe:

• An online service builder with the means to map data to XML (eDesigner)
• The means to create a trackable process (OpenProcess)
• The means to surface trackable processes online (OneVu)
• The means to update a customer when notes are added/statuses are completed

So, what was missing from our ingredient list?

The means for:

a) A back-office system to be passed data in a manner it understood

b) A back-office system to be able to provide automated updates as activities were taken in said system

The solution was elegant and twofold. 

Firstly

We provided the means for a user to create new type of trackable process in OpenProcess that was capable of automatically calling a back-office API upon creation. By doing this we could pass the unique/secure details associated with the trackable process in question. Let’s call this process id. Now the back office contains the task to be done but, importantly, it has the context (process id) of the trackable process.

Secondly

We needed to ensure there was a secure mechanism of updating the trackable process when activities occurred in the back office. To that end we built a set of APIs that would enable a user to:

1. View documents created when the online form was submitted - the form & evidence uploaded

2. Add a note that will automatically notify the customer of the update and that they can see within their trackable process

3. Update/complete a task and will automatically notify the customer of the update and that they can see within their trackable process

Practicing what we preach, these APIs were delivered using the best practice from GDS e.g.

• Using RESTful
• Using HTTPS
• Using JSON
• Document your API

For the latter we actually built a Swagger UI function into our OpenProcess product to enable the APIs to be seen and tested by users.

This is similar to what the DfT has done with the APIs it has provisioned for its Blue Badge APIs.

The result

With these two elements added we have enabled 3C Shared Services to deliver exactly what their requirement was in a way that benefit all of our eDesigner/OpenProcess users . 

Initially, the three councils will be using this for around 20 online forms that will integrate to Yotta’s Alloy solution and cover environmental health service requests.

This enables low/no code delivery of digital services with a complete feedback loop built in for any service. The definition of lego government in digital transformation.

*3C Shared Services provides operational / technical /digital support to Cambridge City/Huntingdonshire District/South Cambridgeshire District Councils.