A new employee might waste ten minutes just figuring out which box to tick on a screen — and that wasted time adds up across an entire company. That is the core problem that 'Forms and Views' solve in ServiceNow: making sure the right information appears in the right order for the right person. For the CSA exam, mastering forms and views means you can transform a cluttered data-entry screen into a streamlined tool that guides users, prevents errors, and makes service management feel effortless.
Jump to a section
A simple way to picture Forms and Views
In a busy office supply store. You walk in to buy a notebook, but every notebook on the shelf is identical: same cover, same line spacing, same number of pages. For a project manager who needs a daily planner with a calendar section, a contacts page, and a budget tracker, this one-size-fits-all notebook is useless. They have to flip through pages they do not need, scribble out sections, and tape in extra sheets. It slows them down and makes their work messy.
Now imagine the same store offers a 'notebook builder' kiosk. You select the cover colour, choose between lined or grid paper, add tabs for different sections, and even decide which pages appear first. For the project manager, that means they can create a planner with a month-at-a-glance page at the front, followed by weekly task lists, then a budget tracker, and finally a contacts directory. They leave with a perfect tool that matches exactly how they work.
In ServiceNow, 'Forms and Views' are that kiosk. The default form is the plain notebook — it shows every field in a standard layout. But administrators use 'Form Design' and 'Form Views' to rearrange fields, hide unnecessary ones, and create different layouts for different teams. Just like the customised notebook saves time and frustration, a well-configured form lets a user enter incidents in seconds rather than minutes.
At its simplest, a 'Form' in ServiceNow is a web page where a user enters or views information about a single record. A 'record' is one row in a database — for example, one incident ticket, one change request, or one hardware asset. Every record belongs to a 'Table', which is the database container that holds all records of that type. The 'Incident table' holds all incident tickets, just like a spreadsheet tab holds rows of data.
When you open any record, ServiceNow shows a form. By default, that form displays every field defined in the table, in the order the table was created. For a beginner, this default form can look overwhelming — dozens of fields like 'Assignment group', 'Caller', 'Category', 'State', 'Priority', 'Short description', and more. Many of those fields may be irrelevant to the user's job. A help desk agent does not need to see 'Cost' or 'Vendor' while logging a password reset.
This is where 'Form Sections' come in. A Form Section is a collapsible grouping of related fields within a form. Think of it as a folder inside your notebook. Instead of a flat list of fields, you organise fields into logical groupings: 'Contact Information', 'Issue Details', 'Resolution Information', and so on. Sections can be expanded or collapsed by the user, hiding low-priority details until they are needed.
Form Sections are defined in the 'Form Layout' configuration. An administrator drags fields into sections using the 'Form Designer' — a visual drag-and-drop interface. You can reorder fields within a section, rename section headings, and even add a section with no fields (useful for spacing). Every form has a default section called 'Default' where all ungrouped fields live. Good practice is to move all relevant fields into named sections and keep the default section empty.
Now, what if different teams need to see different things? A Level 1 support agent might only need 'Short description', 'Category', and 'Priority'. A Level 2 engineer needs those fields plus 'Configuration item', 'Assignment group', and 'Resolution notes'. Using a single form layout would frustrate both groups. The solution is 'Form Views'.
A Form View is a saved, alternate layout of the same form. You can create one view called 'Level1 Support' and another called 'Level2 Support'. Each view can show different fields, in different sections, in different orders. When a user opens an incident, ServiceNow automatically shows the view that matches their role — or they can manually switch views using a dropdown menu at the top of the form.
Views are created and managed in the 'Form Designer' under the 'Views' menu. You can also set a 'View rule' — a condition that automatically applies a specific view based on criteria like 'User role is ITIL' or 'Department is Finance'. This automation ensures the right people see the right layout every time, without manual switching.
Why does this exist? Before ServiceNow, many companies used custom-built applications or paper forms. Every time a process changed, someone had to edit the application code or print new forms. ServiceNow provides a no-code / low-code alternative: an administrator can reconfigure forms in minutes using a web interface, without touching a single line of code. This agility is one of the platform's core value propositions.
What does this replace? In legacy systems, managing different user needs often meant building separate applications — one for support agents, one for engineers, one for managers. That approach created data silos and maintenance nightmares. With Forms and Views, a single application (like Incident Management) serves all roles through the same underlying record, just presented differently. Data stays consistent; the user experience adapts.
Open the Form Designer
Navigate to any table (e.g., Incident table) and click the 'Configure' icon in the form header, then select 'Form Layout'. This opens the Form Designer — the central tool for editing forms and views. Without this step, you cannot make any changes.
Organise Fields into Form Sections
In the Form Designer, drag fields from the 'Default' section into new or existing sections. Create sections by clicking 'Add Section'. This step groups related fields logically — for example, putting all contact fields into a 'Contact Information' section so users can find them quickly.
Reorder Fields Within a Section
Drag fields up or down within a section to define the order they appear. The topmost field appears first on the form. This matters because users scan top to bottom; placing the most important field (like 'Short description') at the top improves speed and accuracy.
Create a New Form View
In the Form Designer, click the 'Views' dropdown and select 'Create New'. Name the view (e.g., 'Agent View'). This duplicates the current layout as a starting point. You now have a separate canvas to edit without affecting the original view.
Customise Fields for the New View
In the new view, remove fields that are irrelevant to the target audience by dragging them back to the 'Available' panel. Add fields that are needed but were hidden. This step tailors the form — for example, hiding 'Resolution notes' from agents but showing them to engineers.
Set a View Rule (Optional but Recommended)
Go to the 'View Rules' related list on the table's configuration page. Create a rule that applies the new view when a condition is true (e.g., 'User role contains incident_editor'). Without a rule, users must manually select the view from a dropdown — automation saves time and ensures consistency.
Test the Configuration
Log in as a test user with the target role and open a record. Verify that the correct view loads, that fields appear in the right order, and that hidden fields are genuinely absent. Testing catches mistakes like accidentally hiding a required field.
Sarah is a ServiceNow administrator at 'BrightPath Logistics', a company with 2,000 employees. The company uses ServiceNow for incident management, change management, and service requests. Sarah's first task is to improve the incident entry form because help desk agents are complaining that it takes too long to log a ticket.
Step 1: Sarah talks to three Level 1 agents. They tell her they only ever fill out eight fields: Short description, Category, Impact, Urgency, Caller, Contact type, Description, and Assignment group. The form currently shows 25 fields, including 'Configuration item', 'Business service', 'Cost', and 'Vendor' — fields they never touch. Sarah opens the 'Incident table' and launches the Form Designer.
Step 2: She creates a new section called 'Essential Details' and drags the eight commonly used fields into it. She then creates a second section called 'Additional Info (for when needed)' and places less common fields like 'Configuration item' and 'Business service' there. She collapses the 'Default' section and moves all orphaned fields into her new sections.
Step 3: Sarah saves the main form layout. The agents test it and say it is better but still shows fields that engineers need but agents do not. For example, 'Resolution code' and 'Resolution notes' appear on the form during creation — completely irrelevant to agents who only log incidents, not resolve them.
Step 4: Sarah decides to create two Form Views. She creates a view called 'Agent Create' that hides the 'Resolution code' and 'Resolution notes' fields entirely. She creates a second view called 'Engineer Update' that shows those fields plus 'Work notes' and 'Scope'.
Step 5: To enforce these views automatically, Sarah sets a 'View Rule': if the user's role includes 'incident_editor' (the role agents have), the 'Agent Create' view appears. If the role includes 'incident_manager' or 'itil', the 'Engineer Update' view appears. She saves the rule.
Step 6: Two weeks later, ticket creation time has dropped from 4 minutes to 90 seconds. Agents report less confusion. Engineers appreciate that 'Resolution code' is no longer hidden from them. Sarah's manager is happy.
The real-world lesson: forms and views are not just about aesthetics. They directly affect user adoption, data quality, and operational efficiency. A form with too many fields invites errors; a form with too few fields may miss critical data. Views provide surgical precision in tailoring the experience to each role.
The SNOW-CSA exam tests Forms and Views heavily — expect 3 to 5 questions on this objective. The exam wants you to know three things: what each concept is, how to configure it, and when to use each one.
Common question types include: - 'Which component allows you to group related fields in a form?' Answer: Form Section (not Form View, not Form Layout). - 'True or false: Form Views change the fields visible on a record for all users.' The correct answer is false — Form Views control visibility per user or role, not globally. - 'You need to show a different set of fields to agents versus managers. What should you configure?' Answer: Form Views (not Personalised Views, not UI Policies).
Key concepts the exam loves to test:
Form Sections group fields visually but do not hide fields from roles.
Form Views hide/show fields per view and can be assigned by role or condition.
The Form Designer is the tool for modifying both Form Sections and Form Views.
'Personalised Views' are user-level customisations that override admin-defined views — the exam may ask how they differ.
A 'View Rule' is an optional condition to automatically apply a view; without it, users must manually select a view.
Traps the exam sets:
Confusing 'Form View' with 'Form Section'. A trap question might say 'Use a Form Section to hide fields from managers' — that is wrong. Sections group fields visibly; views control visibility.
Assuming changes to the default form apply to all views. They do not — each view is independent unless you edit the 'Default' view.
Thinking that renaming a section affects data storage. It does not — sections are purely presentational.
Definitions to memorise:
Form: The interface for viewing/editing one record.
Record: One row in a table (one incident, one user, one asset).
Table: The database structure holding records of a specific type.
Form Section: A collapsible grouping of fields within a form.
Form View: An alternative layout of the same form, showing different fields/sections for different audiences.
Form Designer: The drag-and-drop tool to configure forms and views.
View Rule: A condition that auto-applies a specific view on a record.
The exam also tests relationship between tables and forms. A single table has one default form but many possible views. If a question asks 'How many forms can one table have?' the safe answer is 'one default form with many views'.
Form sections group fields visually into collapsible panels but do not control field visibility by role.
Form views allow different layouts of the same form to be shown to different users, roles, or conditions.
The Form Designer is the drag-and-drop tool used to create and edit both form sections and form views.
Each table in ServiceNow has one default form layout, but you can create unlimited Form Views for that table.
Changes made to the default form layout do not automatically apply to other existing Form Views.
View Rules automate the application of a specific view based on conditions like user role or record data.
Personalised Views are user-created overrides that take precedence over admin-defined Form Views.
These come up on the exam all the time. Here's how to tell them apart.
Form Section
Groups fields visually within one form layout
Cannot hide fields from specific roles
Applies to the current form layout only
Form View
A separate, saved alternate form layout
Can hide or show fields by role or condition
Can be assigned to users via View Rules
Form View (Admin-Created)
Created by an administrator in Form Designer
Applies to all users who meet its conditions
Can be enforced via View Rules
Personalised View (User-Created)
Created by an individual user via right-click menu
Applies only to that user
Overrides admin-created Form Views
Form Designer
Tool for arranging fields and sections on forms
Changes layout and visibility of fields
Applies to form design globally per view
UI Policy
Tool for setting field behaviour (mandatory, read-only, visible)
Changes behaviour dynamically based on conditions
Applies at record level, not layout level
Default Form Layout
The baseline layout for all records in a table
Changes affect the default view only
Cannot be assigned to specific roles
Form View
An alternative layout for the same table
Does not change when default layout changes
Can be role-specific via View Rules
Mistake
Form sections can hide fields from certain users.
Correct
Form sections only group fields visually; they do not control visibility. To hide fields from certain roles, you need Form Views or UI Policies.
Beginners see that sections can be collapsed and assume that means hidden, but collapsed is still visible when expanded. Access control is a different mechanism.
Mistake
Changing the default form layout automatically updates all existing views.
Correct
Each Form View is independent. Changes to the default view do not propagate to other views unless you edit each view separately.
It seems intuitive that a 'default' would cascade, but ServiceNow treats views as separate configurations to allow distinct layouts per role.
Mistake
You can copy a form from one table to another table directly.
Correct
There is no direct 'copy form' feature across tables. You must manually recreate the form layout in the target table using the Form Designer.
Because tables have different fields, auto-copying would break or require complex mapping, so ServiceNow does not offer it.
Mistake
Form Views are the same as UI Policies.
Correct
Form Views change which fields appear. UI Policies change field behaviour (mandatory, read-only, visible) based on conditions. They are separate tools.
Both affect the user interface, so beginners conflate them. But views are layout-focused; UI policies are behaviour-focused.
Mistake
Personalised Views are a type of admin-created Form View.
Correct
Personalised Views are created by individual users for themselves. They are not managed by administrators and override admin Form Views.
The similar terminology 'view' confuses users. Admin views are global; personalised views are per-user overrides.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Form Section groups fields visually inside a form, like a folder. A Form View is an entirely separate layout of the same form, which can show different sections and fields for different roles.
Yes, you can also use UI Policies to make a field visible or read-only based on conditions, but Form Views are the simplest way to completely remove fields from the layout for specific roles.
Open the Form Designer for the table, click the 'Views' dropdown button, select 'Create New', give the view a name, and then customise the fields and sections for that view.
No. Each Form View is independent. Changes to the default layout only affect the default view, not any other saved views.
It is a built-in section where all fields that are not assigned to a named section reside. Best practice is to move all fields out of this section into named sections.
Yes. Users can create Personalised Views by right-clicking the form header and selecting 'Personalise Form'. These are private to that user and override admin-defined views.
You've finished Forms and Views. Continue through the SNOW-CSA study guide to build a complete picture of the exam.
Done with this chapter?