I work for a local government agency. We use 3rd party contractors and external services A LOT. We’re always bouncing from one “greatest” solution to the next. The latest “greatest” solution is a forms / workflow service called SimpliGov. Like any external / 3rd party tool it’s not exactly what we need, but we’re making good use of this one.
Our public facing website has thousands, possibly tens of thousands, of PDF forms that are available for downloading by the citizens. Applications for business and marriage licenses, adult and child support services, and many other types of applications. Submitting these forms is often the first of many steps in a process that results in services or permits getting issued. Traditionally, and still the case for many of these forms, the process for moving the application through the various steps of review and approval has several steps and can be greatly improved through a digital workflow.
SimpliGov is the latest forms / workflow solutions to be implemented by my agency. Others include K2, OnBase and Accela. Other agencies like ours have even implemented simple workflows using Mcrosoft Sharepoint.
Of these “others,” K2 offers the most robust solution. It’s the “complete package.” It offers integrations with a myriad of data sources, has a robust API service and client and can integrate custom coded DLLs to allow you create the PERFECT solution for your organization. But, it’s extremely expensive and their client-facing UI is living in the year 2000.
Enter SimpliGov. Like most new solutions we use, SimpliGov is a Software As A Service (SAAS) solution. That term (SAAS) is one that gives managers a sense of warmth, but leaves the technical team looking at a wet spot on the floor.
SimpliGov offers a web-based form designer and a web-based workflow designer. The form and workflow are tightly coupled. There are a limited, but very useful, number of controls that can be dropped onto your form. The workflow is created by dropping stages (steps or nodes) onto the designer, then connecting the stages by “drawing” a connector between the two. Each connector provides the ability to add conditions (i.e. when does this path execute?) and notifications (i.e. who needs to know that we’re taking this path?). Each stage allows you to determine which parts of the form are displayed to the user at the current stage (i.e. At the review stage, display the intake form and reviewer inputs).
However, the form designer is one of the pieces that aggravates me to a notable degree.
A form is composed of one or more smaller forms. These small forms are presented as pseudo-tabs in the designer. At runtime, the forms are presented as one long form by default. There is a run-time “Wizard” view which allows you to display each tab as a tabbed element so that the user only views one tab at at time.
For each stage in the workflow, you determine which of the small forms will be visible to the user. For example, in stage 1 (the application step), you can choose the “application” form to be visible, but all others hidden. In stage 2 (i.e. initial review) you can present the application form in “read-only” mode and show the review form in input mode.
The designer has some quirks. If you add a new control to your form, you have to visit every stage and interact with the Forms Access dialog to indicate that this new control needs to be displayed on the form (or not), and whether it is read-only, interactive, or passive. Adding a control to an existing, large form takes a notable amount of time for us to ensure that the control is visible in all the applicable stages of the workflow. More than a little frustrating.
Where’s the Data?
Another “down” item has to do with data supporting your forms. The forms can only display simple, flat table data. There is no access to a database and things like stored procedures are not available in any manner. So there are many lookup operations that are a breeze in K2 that are simply not available in SimpliGov. They do offer a bare-bones take on dependent data, but it is implemented in an embarrassing manner that I won’t go into. Just plain bad.
There is support for calling APIs to populate form fields and controls. However, that then requires us to maintain a public server to provide data to SimpliGov. If I need to stand up a public server to perform database functions for SimpliGov, I may as well create a web application from scratch using standard web technologies.
The right stuff
There are some pluses. The development process if FAST! Implementing a workflow from an accepted design is a matter of hours, not days or weeks. If you take the time to plan around the limitations mentioned above (and many others!) you can produce a workable application very quickly.
Another great plus is their tech support. They use a Zendesk implementation with the standard submission post and post / email response. They’re still small, so their support team responds relatively quickly and you get to know the support staff. They offer links to well-written documentation and can get you to the answer quickly.
As mentioned, their documentation is excellent. It’s a searchable wiki-like system that covers everything that I have needed to find. Well-written and well illustrated. Definitely a plus.
This has been a VERY coarse / cursory overview of SimpliGov. My feelings for this tool fluctuate GREATLY. Some days, things work well and I’m happy. But too often, I’m struggling with something that can be implemented easily using traditional web application concepts, or other tools like K2.