Choosing the correct field type when building a form

To streamline business processes, organizations are looking at ways to automate and improve upon as many manual processes as possible.

For example, the annual company picnic is coming up, and management wants you to improve the haphazard process for making the food order, given that the track record for the last three years has been less than stellar:

1st annual picnic—Too much food was ordered. The leftovers could have fed half an army.
2nd annual picnic—Not enough food was ordered. Stomachs were growling.
3rd annual picnic—Enough food was ordered, but every sandwich contained meat. The vegetarians in the crowd, including the CEO, were peeved.

How can you ensure that the 4th annual picnic will be a success and the food will be a hit? Two words: ServiceNow Forms. In the platform you can build custom forms and tables for capturing and storing data. Why not create a form that employees can fill out to indicate their food preferences, and then run a report and use it to order the food? Great idea—if you do it right.

In this latest installment of our best practices series, we look at an example of how choosing the correct field types impacts the quality of data entered in forms, and thus the resulting tables and reports.

Choosing incorrect field types

To address your picnic challenge, you design a form to collect food preferences from employees. For each food item, you provide a list of the available options, and users can enter text to describe exactly what they want. How could this go wrong?

But notice that all the fields on the form are the string (text entry) type:

This form would collect the data, as expected:

But the values would be so inconsistent that it would be impossible to generate a useful report. Items would have to be manually tallied for the shopping list, which defeats the purpose of automating the process.

Choosing the correct field types

Seeing the error of your ways, you design a new form — but this time you provide users with choice lists for food items with multiple options, and true/false fields for the optional sandwich toppings. Because you choose the correct field type for each form field, the form and list look like this:

Controlling the values entered into the form allows you to create useful reports. In this example, the report facilitates ordering ingredients for making sandwiches in batches:

Certain field types are better than others for particular kinds of data. Before creating form fields, consider what kind of data will be entered in the form and what you want to do with that data. Also, become familiar with the available field types, so that you can select the best type to capture the expected data and process it to provide meaningful information.

Examples of form field types

Use string fields if consistent data is not required and you want to provide flexibility for users to respond however they want to:

Use choice lists, reference fields, or other variable types to constrain options and prevent typos and spelling variations that often occur in string fields. For example, choice lists let users select from a pre-defined list of options:

Use reference fields to allow users to select data from a field in another table in the instance. Here, Jonathon selects his name from the Name field on the User [sys_user] table:

Use true/false fields to indicate binary responses such as true/false, yes/no, or agree/disagree. These fields appear as check boxes that the user selects or clears:

What can you do if you need to change the field type after a form is in production?

Changing a field type after the form is in production is not recommended because it can result in data loss. Instead, create a new field with the correct type and migrate the data from the old field to the new field. Then do one of the following:

Delete the old field if it won't have negative impact, for example on users who have created reports with the old field.
Adjust security rules to prevent users from creating new reports with the old field.
Re-label the field to something like "OLD FIELD—do not use!"

If you must change a field type, follow the guidelines in Valid data type changes.

For more information, see:

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.

To access all of the blog posts in this series, search for "nowsupport best practices series."