Forms, Lists, Modules, UI Policies, and Client Scripts

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, and modules are the links underneath it. A module can open a list, a New Record form, a specific record, an external URL, a report, a Service Catalog item, or a homepage. Each module has a Link type that determines that target.

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 carry a built-in filter (an encoded query) so users land in a useful queue immediately — for example active=true^assigned_to=javascript:gs.getUserID(). The module Roles field controls whether the link is visible to a persona, and the Order field controls sequence within the menu. This is navigation design, not data security: a user who cannot see a module can still reach the records by URL if the ACLs allow it.

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 never adds, removes, or secures a database field.

A view is a named layout variant for forms and lists. Views let one table serve different personas or tasks. A Requester view may show description, status, and comments, while an Admin view adds assignment, lifecycle fields, and troubleshooting data. View rules and role-based view selection can route users to the right layout automatically, but the underlying table is unchanged.

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 reaches the record but cannot see a field, inspect views and field ACLs. If the field does not exist at all, inspect the dictionary.

UI Policy Before Client Script

A UI Policy is the first choice for straightforward form behavior. Through UI Policy Actions it can make fields visible, mandatory, or read-only based on a condition, with no code. Because it is declarative it is easier to maintain than custom JavaScript and clearly communicates intent to the next developer. UI Policies have an Order field and can run scripts in their Execute if true / Execute if false sections for edge cases, but the simple actions cover most needs.

A Client Script is browser-side JavaScript bound to a table and a type:

• onLoad — runs when the form renders; use it to set initial UI state.
• onChange — runs when a watched field changes; receives oldValue, newValue.
• onSubmit — runs at save; return false to block submission after validation.
• onCellEdit — runs on inline list editing.

Use a Client Script when the requirement needs logic a UI Policy cannot express: showing a custom g_form.addInfoMessage(), calculating a form-only value, or calling a Script Include asynchronously through GlideAjax. Prefer g_form and g_user APIs; avoid synchronous server lookups (GlideRecord getReference without a callback) that freeze the browser. Order matters: when both apply, UI Policies generally run after Client Scripts on load.

Client-Side Behavior Is Not Enforcement

UI Policies and Client Scripts improve the interactive form, but they are not the final authority for data or security. They do not protect secrets, and they do not run for import sets, REST integrations, background scripts, or direct server-side updates. If a rule must hold outside the browser, move enforcement to a Data Policy or Business Rule. If data must be protected from unauthorized read or write, use an ACL. If a Client Script needs server data, call a narrowly scoped server method through GlideAjax instead of embedding privileged logic in the browser, where a user can read or alter it.

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.