Repeatable subforms.. is it time for V2?

[lauramiddleton]

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

Issue:

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.

Example:

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.

Impact:

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)

Issue:

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.

Example:

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.

Impact:

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!

This topic was escalated to Salesforce Case 03994297 on 07-22-2021 07:33 AM by an automatic escalation.

[LisaJM]

Hello Laura,

Thank you so much for a thoughtful and informative post! I do look forward to seeing what additional comments your fellow govService users may have on this thread.

In the meanwhile, I have marked the post and submitted for further review by our internal product team members.

Thank you for sharing your thoughts with us!

Best,

LisaJM

[ryanleanoon]

Completely in agreement with this! Unfortunately Granicus is aware of our issues with repeatable subforms and in my experience frankly aren't being overly quick or helpful with support at present (citing support charges at every support juncture... even to identify and fix an issue on their end). 
We are using an API to pull numerous questions to create a booking form, effectively, automatically. To do that, we need to use subforms and for each question and answer within that subform to be identifiable except, when you do that, the data name for both stays the same over each iteration.

Example: I have a repeatable subform calling an API lookup for the question. Within the subform, using the question ID, I call another lookup on a dropdown for the options that are available for that question.
These are both given the data names "question" and "answer", but so is every other one repeated after it. There is no way to give it a number, i.e. question1, answer1, question 2, etc. for each iteration... Why? 

Also, Granicus what is with your support articles having videos that aren't available and links leading to the old firmstep.com pages? 
Introduction to Subforms | Granicus Support
Display Conditional or Repeatable Content Within Integrations | Granicus Support
Error (granicus.com)
https://customers.firmstep.com/support/?destpath=/support/discussions/topics/13000017736