Showing results for 
Show  only  | Search instead for 
Did you mean: 

Escalate Topic

Repeatable subforms.. is it time for V2?

Changemaker II
At Waltham Forest, we are heavy users of repeatable subforms. Whether it’s capturing data about people living in a household, returning information about waste and recycling collections at a property, or allowing customers to add chargeable products and services to their basket, you can usually find a repeatable subform of some kind (hidden or exposed) in most of our forms!
After spending years running into the same issues when designing and building our processes, we feel that subforms is crying out for a V2 (or for some of the limitations and issues with the existing version to be addressed). We have had multiple discussions with Granicus on the subject and they have suggested that we reach out to you - our fellow govService users - to gather feedback, gauge interest/appetite for a V2 and generally get the conversation flowing!     
There are a couple of things which we believe subforms are missing:
1) The ability to capture responses from integrations running against a repeatable subform

While you can currently set an integration to repeat against a subform (on pre-submission, submission or creation of any given stage) it is not possible to capture the response within the subform entry each time it fires.
You may have a form which captures the details of everyone living at an address.. think Council Tax or Housing. On submission, you want to create a record for each of those customers in a third-party system and capture the ID/reference for each newly created customer. The returned IDs/references may need to be referenced in subsequent integrations on the form or may need to be presented to users at a later stage in the workflow.
Without this functionality, we are having to create a middle layer in SQL server which receives the form data, fires the relevant integration, captures the response and stores it against the corresponding originating record. This adds a huge amount of complexity (and, in some cases, latency) especially when there are multiple integrations firing in sequence.
2) The ability to edit subform row data via the summary view (without having the expand the subform entry)
When repeatable data is presented using either the ‘summary’ or ‘popup’ view, the user must click into each individual subform row (which then expands the record) in order to edit any the field values. Without wanting to sound like that customer, this is something which old AchieveForms handled extremely well, almost treating the subform as an editable table.
You may have an admin form which presents multiple open govService cases to the back-office. The staff may then want to bulk approve/close/re-assign those tasks quickly and easily by ticking a box against each relevant record.
Without this functionality, bulk updates of any kind become extremely time consuming (especially when coupled with the bug where the screen jumps around each time you open and close a subform entry).
And then there are a various other smaller issues which we would love to see fixed, most of which are covered in the 29 ‘known issues’ listed on the Granicus wiki. One scenario which isn’t listed however is if a subform is populated by a lookup and the subform is mandatory, you must declare every single field in the lookup (mandatory or not) else the subform does not load. If you do not hold any data for a particular field, or you want to leave it blank for the user to complete, you must return a ‘’ value in the query.
We would love to hear from anyone who has been experiencing similar issues with repeatable subforms or has any further suggestions on how they could be improved! We really do feel that they are fundamental to good process and data design and, with a few tweaks (or a complete rebuild), could really enhance the experience of both front and back-end users.
Thanks for reading!