Things to remember when designing an intake or other record creation form
You have two types of record creation form in Autologyx Catalyst, both of which are designed specific to an object class:
The Create and edit view – configured under the Display tab of the object class – only logged-in users with the appropriate permission will have access to this form to create records. The same form is presented when a user edits a record in their Records list.
A standalone form – configured under the Forms tab of the object class. This has a URL which can be made available to both users or non-users for record creation. This is the option you are more likely to choose.
Both forms use the same Catalyst form-builder which allows the designer to present class fields in sections with up to 3 columns. There is also the ability to use conditional logic to display columns on the basis of inputs into previous fields.
If you think of an intake form as a checklist, you should be able to get all the information required to start the process along the appropriate route. Clever use of different field types and instructions will mean that the data will be in the correct format – that’s really important for sub-processes in your automated workflow and, of course, for any reporting you might provide to the business either during or after the event.
People generally dislike filling in forms. However, there are some really basic rules to follow when designing your forms which will lessen the annoyance of the user. At the risk of stating the obvious, these include:
- Ask everything needed. As a minimum, the form needs to capture all the information needed to start the process, including data used in system decision-making as to who or which team it should be assigned, as well as which tasks must be created for it. It’s not a great use of anyone’s time to sequence a task or automate an email to the form submitter because they haven’t provided all the required information.
- Use conditional logic. Use the conditional logic feature so that you only present relevant questions based on the answers to previous questions. In addition, avoid asking questions where the answer is already known – even if it is held in a different object class.
- Use familiar terminology. Use terminology that the user is familiar with and keep questions as short and precise as possible.
- Keep instructions short and clear. Use the Instruction widget to add notes where they will help the user, but keep these short and clear. The action button at the bottom of our stand alone forms is labelled “Submit”. You might consider using an instruction to explain what will happen when the form is submitted.
- Present questions in a logical order. Present the questions in a logical order so that the user isn’t jumping about to find information. Some people suggest starting with easy, quick-to-complete type questions to make the user feel as if they are making good progress.
- Make workflow-driving questions mandatory. Questions where you are collecting information which will determine the appropriate automated workflow route (via your sequences) must be mandatory.
- Include space for anything else relevant. An open question at the end of the form is useful for the user to provide any other relevant information. A short while after the form goes into live use, you might find it useful to review these answers and either amend or add questions to allow a more efficient data capture of the type of information given.
View our article describing the field types available in record creation forms.
In the meantime, some considerations which should aid your form design
Choose the right field type
Catalyst has a number of different field types. It should go without saying, but ensure that you use field types which allow you to validate, ie Date fields to capture dates. We also have a Date/Time field type which is useful for meeting confirmations, etc. There are two Number type fields: Integer for whole numbers and Decimal for those which are not. The same applies with email addresses to be captured in the Email type field and all phone numbers in the Phone type field. Consider the appropriate field type for data capture in Catalyst if it is to be passed via API to a third party system or to be merged into documents or email messages.
Use text fields appropriately
The least useful as far as determining the workflow automation route is “Text”. However, this is useful for capturing supplementary information or for providing fields for names or other information which cannot be chosen or pre-determined. One thing to bear in mind is to choose “Single line” for one word or short sentences and “Multi line” where you are expecting more detail.
Think about how options are displayed
Single select fields can be displayed as a drop-down list, which will save space, or radio buttons. People like to see options, but if you have more than four, the form can become ugly, so the drop-down is preferable on these occasions. Our multi select fields are always displayed as tick boxes so that all users can clearly see which options have been chosen.
Checkboxes in Catalyst are always used for one option. They are useful to get the form submitter to confirm or agree to a statement.
Remember the limitation on placeholder text
Catalyst fields don’t support placeholder text. This isn’t necessarily a bad thing, as it can be confusing. However, we often create single select fields, displayed as a drop-down, with a first option which prompts the user about making their selection, eg “Choose the option which most closely describes the current status of the claim”.
Consider making a field unique
One final but really important thing to consider is marking one field as unique – most commonly a text field. This will prevent duplication of records.
Testing the form
Start with internal testing
Internal users should test the form first. They will be able to provide feedback on the logic, spelling and grammar, and all the obvious issues which you as the form designer won’t be able to see.
Then test with less familiar users
Following this, ask colleagues from a different team or those who aren’t familiar with the use case to test for you. It can be useful to watch these user complete the form so that you can see where they find it difficult or get stuck.
Finally, test with external users
Move on to testing with friendly external users and don’t stop until one flies through it without issue of query.
When the form does go-live, you could consider including a field asking for optional feedback or suggestions for improving the form. Just because it's live, that doesn’t mean it’s the best it can be!