O
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.
–Navigation:
System UI -> Forms (or type ‘sys_ui_form.list’ in your left nav filter)
–Usage:
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).
–Navigation:
System UI -> Forms (or type ‘sys_ui_section.list’ in your left nav filter)
–Usage:
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.
–Navigation:
Type ‘sys_ui_form_section.list’ in your left nav filter (or view the ‘Form Sections’ related list on any Form or Section record)
–Usage:
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.
–Navigation:
System UI -> Views (or type ‘sys_ui_view.list’ in your left nav filter)
–Usage:
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.
Hey Mark
Quick question-
How can we inherit the sections present in the task table to others.?
The default view/form section of a parent table is automatically used if you access an extension of that table without any default view/form defined. Other than that, there’s no way to inherit form sections. They’re all explicitly defined for each table.
Hi Mark,
Is it possible or have you ever seen a request to align the Related List Sections with the Form Sections? So lets say you’re looking at a change request form and you want to see the ‘approvers’ related list next to the ‘schedule’ section when viewing form in tab view?
You can’t arrange all of the tabs in a row, but it’s possible to embed a related list in your form section. I hate embedded lists because they really don’t work the same way as standard related lists and they’re difficult to manipulate with client scripts. I wouldn’t recommend it but here’s the link to show you how it’s done.
http://wiki.servicenow.com/index.php?title=Embedded_Lists
“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”
Or if you want to use an existing view for extra tables, for instance creating a Self Service (ess) view for Change Request. (though I’m still trying to figure out how to make that work properly. I have bad experiences in manipulating forms and sections in their applications and getting the information safely on the other site through an update set)
You can use an existing view for extra tables without issue. Just be sure to use the true existing view name when adding the view for the table. For example, if I wanted to use the ‘Self service’ view for the change request table, I could just specify ‘ess’ when personalizing and adding the view.
Thx for that tip: I added “Self Service” as view, and then you get errors. After adding “ess”, you see that it is automatically translated to Self Service
HI, how do I create 3 columns of a number of fields aligned to each other? I am only able to make 2 splits, 3rd column goes at the bottom.
Standard ServiceNow forms only support a 2-column layout currently.
Oh. There shouldn’t be a limit. Oh well.
Hi that is really helpful to understand form section I am trying to hide the Configuration section on cmdb_ci_solar_server table through client script, the actual problem I am facing hear is two sections are there with Configuration name for two different views one is for Default view another is for Compliance.
When I ran that script Default view section is hidden but Compliance one is not hiding please I believe that names for sections are different but I am not find the names, please let me know how can we fix this issue.