This video covers building a custom order form in Table Builder.
In our scenario, Steven manages a restaurant conglomerate.
The Mexican restaurant branch asks Steven to create an online food order form with delivery options.
Let’s follow along as Steven opens his restaurant management app in App Engine Studio.
Here’s the table he created earlier for customer food orders.
When we open Form views, the default form view appears.
We need to create a new one specifically for Mexican food orders.
The first section of the form is already added for us.
Here we want to capture customer information, so we edit the label and make the section two columns.
Now let’s add a field to the form using the Add icon.
You can also drag and drop fields onto the form.
We start by adding the Customer field, which is a reference field to the User table.
Notice that the field is dimmed in the Fields tab so we can’t add it to the form again, which could cause an error.
We also want this field to show the logged-in user by default.
In the Configuration panel, we change the default value to use dynamic default, and select Me from the menu.
Now we want to add related fields from the user table for the customer’s first and last name.
We drag and drop the Add a related field block to the form, search for the field, and add it to the view.
We can also add a field by clicking the Add icon here.
Finally we add the customer’s mobile number, …
…and save our changes so we can preview the form.
The form fields display the logged-in user’s information, but they’re also editable.
We want all these fields to be read-only.
Because the user field is a direct reference to the user table,...
... we can set the field to Read Only or Mandatory in the Configuration panel.
Now let’s make the other fields read-only.
Notice that Read Only and Mandatory aren’t available in the Configuration panel because these fields are related fields.
But we can use a UI policy to control them.
We won’t set any conditions because we want the fields to always be read-only.
We can set all the user information fields to read-only in one UI policy.
The first field name is selected for us.
For the remaining fields, we need to dot-walk from the customer field.
The fields are marked with a badge showing that they’re affected by a UI policy,...
... which also displays in the UI policies tab.
When we save and preview the form,...
... we see that the UI policy is working correctly.
Now let’s add a new section to the form for the food selection.
We want to filter the options for this field so that it only shows Mexican food items.
To do this we set up a reference qualifier, with the condition that Cuisine is Mexican.
Now let’s add another new section to the form,...
... but this time we’ll drag and drop it from the Components tab.
We want this to be a two-column section,...
... but we want to merge it with the previous section so they appear to be one section.
So we select the Merge with section above option.
Now let’s add the fields to this section.
For the preferences field, we want the user to select their preference for protein but we need to add the choices: …
…beef, …
…seafood, …
... pork,...
…chicken, …
And of course, vegetarian.
Now the preference field shows the choices we just added.
We want to make the protein field dependent on the preference field,...
... so when the user selects a preference, the protein field provides options based on that choice.
To do this we switch the Use dependent field property for the protein field to On, and select the dependent field.
Now that we’ve selected the dependency, the choices from the preference field appear,...
... but we don’t have any defined.
So let’s set up the choices for proteins.
We choose to show options in a dropdown menu, and start adding the choices.
In the value field, we use underscores instead of spaces.
Now that we’ve added our choices, we drag them to the correct preference.
We can change the order of the choices in the dropdown by dragging them, or using the ordering options.
Back in the form, we can see that the choices are populated, in the order we specified.
Now let’s save and preview the form to test the fields.
When we choose Pork in the Preference field,...
... notice that the only options in the Protein field are Carnitas and Al Pastor.
Now let’s see how to set conditions for a field.
We want only these options to display in the toppings field: where the name is Guacamole or Cheese or Hot sauce.
We have a field for rice, but we forgot to add a field for beans when we built the table.
We can add a new field to the table right from the form.
For this field we want a None option, in case the customer doesn’t want beans.
Now we add the choices.
Let’s move the Beans field to the other column.
We decide we like it better where it was, so we click the undo button to undo that action.
On second thought, let’s redo that action.
Table Builder tracks all your changes, so you can undo or redo any actions since you last saved the file.
Now we’re going to create a new section for additional information, where we add the field for special instructions.
Let’s add the final section with two columns for delivery instructions and merge it with the previous section for a more cohesive look.
We add the Delivery field,
Then we add the customer’s street, …
…city, …
…and state.
We want to hide the customer’s address if delivery is false, so let’s add a UI policy for these fields.
This time, let’s add it in the Policies and Rules tab.
In Advanced Settings we select the reverse if false checkbox, so the fields will appear when delivery is true.
Now we set the street, city, and state to be not visible when the condition is met.
Let’s save the form and preview it.
When we select the delivery checkbox, the fields appear, so the UI policy is working.
But what if the customer wants the food delivered to a different address?
We can handle this use case by adding another field to the form that lets the user indicate whether to use the address on file.
We’ll add a UI policy to this field.
Notice that when we add the same condition as another policy,...
... a prompt lets us open and edit that policy.
This way, we won’t end up with multiple policies that do the same thing.
We add an action to make the Use address on file field visible only when delivery is selected.
In addition, we want it to be true by default, so we add that in the default value field.
But we also want the address fields to be editable when the field is false,...
... so the user can enter a different address.
To do that, we add a new UI policy.
We’ll select reverse if false, and set the condition to when Use address on file is true.
And we set the address fields to be read-only.
Let’s save and preview the form.
When we select Delivery, Use address on file is selected, and the address fields are read-only.
But if we clear the checkbox, the address fields become editable and the user can enter a different delivery address.
So, in just a few minutes, we saw Steven build a custom form for the Mexican restaurant branch to handle food orders with delivery options.
For more information, see our product documentation or knowledge base.
Or ask a question in the ServiceNow Community.