We want re-use fields on a Service Request form where we use a Dynamic Section to determine the activity. This way changes to those fields only have to be made in one place. However, depending on the action, sometimes that field should be mandatory and other times it can’t be. This is forcing us to either risk not marking the field mandatory or use multiple fields with very similar names which then need to be separately updated each time.
For example, we want to use a form for all aspects of a door access card including:
- Requesting a card
- Changing the list of rooms begin accessed
For this, we have a multi-select field called “additional access” that lists all possible rooms and opens a dynamic field to collect more data:
- On the original “requesting a card” option, the “additional access” field can’t be mandatory field since the person may not need any special access. But we’d need to give the option in case they do.
- On the “changing list of rooms” request, that same field should be mandatory. But marking it as mandatory, affects both dynamic sections so we can’t.
In an ideal world, each time you use a field within a Service Request form you should be able to specify whether that specific use of the field is mandatory without impacting other uses of the field.
Similarly, we would like to tie requiring an attachment to specific activities on a form.
- For the initial card request, the requestor is required to supply a photo of themselves as an attachment so we’d like to mark “attachment” as mandatory.
- When making any other changes after a card has been issued, we don’t need a new photo supplied therefore we can’t make attaching a file mandatory.
In the instance of attaching a photo, our only option is to create a unique form for the initial card request and a use one or more additional forms for all other card-related requests. We find that, if customers need to spend more than a couple seconds looking for the right form, they fall back on just logging it as a support ticket causing rework and frustration. For that reason we want to keep the catalog of forms as small as possible by consolidating related requests into a single form with internal dynamic fields to tailor the gathered data.