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.
  For 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.