ne of the most basic things you learn as a Service-now.com administrator or consultant is how to personalize a form. I remember when I was first introduced to Service-now how cool it was that you could just right-click and manipulate the fields on a form or a view. Service-now added more flexibility later with the introduction of form sections and tabbed forms.
This ease of use didn’t really translate for me when it came to understanding what was really going on behind the scenes. If I ever ran into a problem with my form or needed to change the arrangement or labels of existing form sections it seemed to take me forever to find the correct place to make the change.
This post is written to hopefully eliminate some of the confusion with how forms, sections, and views relate and are stored in Service-now. I’m not going to go into any of the standard personalization details because those are all outlined in the wiki. Below is an outline of the table structure, relationships, and usage of forms, form sections, and views.

Form – ‘sys_ui_form’:

Container for multiple form sections. A form section only exists if a table has a view that includes multiple form sections (sections). Each form record must be associated with a corresponding view record (even if the view is the default view). It is possible to have multiple form records for a particular table, each associated with a different view and sections.


System UI -> Forms (or type ‘sys_ui_form.list’ in your left nav filter)


Forms should only be created by personalizing a form and creating a second form section for a view. The only reason to modify a form record directly would be to change the view that the form is associated with. Form records can be useful for navigation purposes when you want to see what form sections are part of a given multi-section form. The ‘Form Sections’ related list on the ‘Forms’ default view is also the best place to change the ordering of form sections on a given form.

Form Section (Section) – ‘sys_ui_section’:

This table is called ‘Form Section’, but it might be clearer to think of it just as ‘Section’. A section is collection of form section elements (fields, splits, annotations, and formatters) displayed on a form. Each section record must be associated with a corresponding view record (even if the view is the default view).


System UI -> Forms (or type ‘sys_ui_section.list’ in your left nav filter)


Sections should only be created through the ‘Personalize Form’ UI. You may need to access these records directly if you want to see what elements are part of a particular form section or if you want to see if the form section is part of a multi-section form. You can also change the view a form section is related to or the caption for a section from the form section record. Section records are really the one place where forms, sections, and views are all linked together. As such, they are usually my starting point for navigation when I’m trying to modify something form-related that can’t be changed through the ‘Personalize Form’ UI.

Form-Section (m2m relationship table) – ‘sys_ui_form_section’:

Probably the most confusing of the bunch until you learn what it is. Contrary to what the label leads you to believe, this is not a form section at all! The ‘Form Section’ table is just a many-to-many relationship table that links forms and form sections (sections) together. This link is only created when you create a multi-section form.


Type ‘sys_ui_form_section.list’ in your left nav filter (or view the ‘Form Sections’ related list on any Form or Section record)


If you’ve ever had a form section “disappear” on a multi-section form then this was probably your problem. The fix for those issues is typically just to create a new relationship record between the form and section in this table. You can also modify the ordering of form sections on a multi-section form by modifying the ‘Position’ field on these records.

The out-of-box Change Request form for the default view shows how all of these elements link together.

View – ‘sys_ui_view’:

Container for forms, form sections, lists, and related lists (all of which can come from various tables). A single view name can be used across many tables. For example, the ‘ess’ (Self-service) view is used by form sections on the Incident, User, and Request tables (among others) out of box.


System UI -> Views (or type ‘sys_ui_view.list’ in your left nav filter)


Views should always be created through the ‘Personalize Form’ or ‘Personalize List’ UI. The only reason you would need to modify a view record is if you want to change the name of the view. Since views can apply to multiple tables, forms, lists, and related lists there’s a lot of information contained underneath a view record typically. It can be useful as a reference to see how all of the pieces fit together though. One thing to keep in mind when working with view records or references is that the majority of the forms and form sections in the system relate to the ‘Default’ view.