Having an app with a lot of fields with a multi-step process can be overwhelming not just for app builders, but users as well. A good way of dealing with this is by separating the record into multiple forms and then adding a process so that the user can only see the form that they are currently on and this moves forward automatically as the user goes through the record. - For a video on this please click here
Setting up the forms
Organise your fields and templates so that you have a clear process in mind and know how many forms (steps) you need.
You need to have a clear point at which each step is complete - e.g. a select field marked as complete/with a specific value in e.g. status field.
Set up each of your steps in their own separate forms like so:
You can then use form rules to hide and show these forms for each stage.
In this example, the forms are dictated by the ApprovalStatus field which is a selection with the following options:
So there are four forms, each with a corresponding select option. This means that the forms are dictated from this selection field so that the user can only see the form of the stage that they are currently on.
This means that the form rules are simple to dictate as the form needs to be hidden when the approval status is not the stage of the form. This means that you will need a form rule for each form which uses a filter that says that any status other than the one that they are on would hide the form, this means that no specific team or template needs to be selected:
Here is the filter for each form:
$filter=[ApprovalStatus] ne 'Draft'
🟡Waiting Approval Form:
$filter=[ApprovalStatus] ne 'Proposed'
$filter=[ApprovalStatus] ne 'Approved'
⛔Not Approved Form:
$filter=[ApprovalStatus] ne 'NotApproved'
For all of the forms except the first one you want the user to see (In this case, the '🔴Draft' form), you will need to select the "Hide Form When Adding New Records?" toggle - this will ensure that the user doesn't see all of the forms at once when they add a new record.
The selection field we used had a default initial value so that it is never empty - this ensures that the draft form shows when the approval status field has not been changed.
Then, when the fields have been filled out, the user is guided to submit the idea for approval like so:
Clicking the submit button will trigger a workflow which will send an email to the email address shown, put in the date that it was submitted and also change the value of the ApprovalStatus field to "Submitted for Approval". This workflow looks like this:
For the email action node, use your own specific email template and include any details that you see as relevant. For more information on sending emails or messages, click here.
The other two action nodes are Update Field Values, for more information on these, click here.
For the user, this will change the form to "Waiting Approval" like so:
When this has been submitted, the next step is for admin to check the idea and select whether it has been approved or not. This template can only be seen by admin, so for this, a form rule is needed to hide this template for all teams except for admin. The filter ensures that this rule is always in place, so we have used the ideaname as not being 'XXX' as this will always be the case and the ideaname field is required so must be filled in. The form looks like this and means that only the admin team see the template, for more information on form rules, click here.
Then, when admin select the status as either "Approved"" or "Not Approved", the form will change accordingly.
This process ensures a seamless process for the user and allows you to dictate which templates and fields the user sees at each stage.
We hope this helped!
Please sign in to leave a comment.