Forms, Lists, Modules, UI Policies, and Client Scripts
Key Takeaways
- Application menus and modules create the user's entry points; module roles and filters improve navigation but do not replace ACLs.
- Forms show one record and lists show many records; views tailor which fields and layouts appear without changing the underlying table schema.
- A form or list view is presentation, not security, so sensitive fields still need ACLs even when they are removed from a layout.
- UI Policies are the preferred declarative tool for straightforward client-side field behavior such as visible, mandatory, and read-only changes.
- Client Scripts run in the browser for logic that UI Policies cannot express, but trusted validation, secrets, and authorization belong on the server.
UX Starts With the Way Users Enter the App
A ServiceNow user experience is built from navigation, record surfaces, and client-side behavior. In a scoped app, the application menu groups the app in the navigator, while modules are the links underneath it. A module can open a list, a new record form, a specific record, a URL, a report, or another destination.
Good CAD design makes modules match real work. Use names like My Open Requests, Create Vendor Review, All Active Reviews, or Administration instead of exposing every table with generic labels. A list module can include a filter so users land in a useful work queue immediately. The module Roles field controls whether the link is visible to a persona, and the Order field controls sequence. This is navigation design, not data security.
Forms, Lists, and Views
A form displays one record. A list displays many records from one table. Both are presentation layers over the same table data, so changing a layout does not add, remove, or secure database fields.
A view is a named layout variant for forms and lists. Views let the same table support different personas or tasks. For example, a Requester view may show description, status, and comments, while an Admin view includes assignment, lifecycle fields, and troubleshooting data. View rules and role-based view selection can direct users to the right layout, but the underlying table is unchanged.
| UX artifact | Good use | CAD boundary |
|---|---|---|
| List module | Open a filtered queue such as My Reviews | Does not grant table read access |
| New Record module | Start a create flow quickly | Does not grant create access without ACLs |
| Form view | Tailor field layout for a persona | Does not protect hidden sensitive data |
| List view | Set columns for a work queue | Does not change the table schema |
| Related list | Show child records connected by reference | Requires correct relationship and access rules |
The exam often asks whether a problem is layout, navigation, security, or schema. If the user cannot find a feature, inspect menus and modules. If the user cannot see a field after reaching the record, inspect views and field ACLs. If the field does not exist, inspect the dictionary.
UI Policy Before Client Script
A UI Policy is the first choice for straightforward form behavior. It can make fields visible, mandatory, or read-only based on conditions. Because it is declarative, it is easier to maintain than custom JavaScript and communicates intent clearly to future developers.
A Client Script is browser-side JavaScript. It runs on form events such as onLoad, onChange, onSubmit, or onCellEdit. Use it when the requirement needs logic a UI Policy cannot express, such as showing a custom message, calculating a form-only value, or calling a server-side Script Include through GlideAjax.
Client-Side Behavior Is Not Enforcement
UI Policies and Client Scripts improve the interactive form experience, but they are not the final authority for data or security. They do not protect secrets, and they do not reliably enforce rules for import sets, REST integrations, background scripts, or direct server-side updates. If a rule must hold outside the browser, move the enforcement to a Data Policy or Business Rule. If data must be protected, use ACLs. If a client script needs server information, call a narrowly designed server method instead of embedding privileged logic in the browser.
A strong CAD answer picks the simplest control that runs in the right place: module roles for entry points, views for layout, UI Policies for simple form behavior, Client Scripts for necessary browser logic, and server-side controls for anything that must be trusted.
A manager wants the Priority field to become mandatory on the form only when Category is set to Emergency. The same rule does not need to run for imports or integrations. What is the best first choice?
Which statements correctly describe CAD user-experience controls?
Select all that apply