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:
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:
- View documents created when the online form was submitted – the form & evidence uploaded
- Add a note that will automatically notify the customer of the update and that they can see within their trackable process
- 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.