Overview
Application User Interface covers how users see and interact with an application's records. You design and customize forms, decide whether a field belongs on a form layout or in the table itself, write client-side scripts that react in the browser, write server-side scripts that run when records are read or saved, and offer a record producer when users should submit a request without facing the full form.
The five objectives share one idea: every behavior has a correct layer. Layout and view changes shape the form; dictionary settings define the field everywhere; UI policies handle simple show, hide, mandatory and read-only rules without code; client scripts handle browser logic that policies cannot; business rules enforce what must hold no matter how a record is saved. The domain sits directly on Domain 1's tables and hands off to Domain 3, where the same records are secured.
How it's tested
Expect scenario questions that name a requirement and list several ways to meet it. Your job is to identify the layer and timing the requirement implies: always enforced or only on the form, before or after save, on load or on change, coded or configured. Multiple-select items often ask which statements about a script type are true, so precise facts matter.
-
Right layer for the rule
Choose between UI policy, client script, data policy, dictionary setting and business rule for a stated requirement.
-
Script timing
Pick the business rule timing (before, after, async, display, query) or client script type (onLoad, onChange, onSubmit, onCellEdit) that fits when the logic must run.
-
Debug the behavior
A script misbehaves and you choose the tool or fix: Script Debugger, session debugging, browser console, or moving logic to the correct side.
A requirement says the Short description must be mandatory whenever Category is Hardware, and options include an onChange client script, a UI policy, a before business rule and a dictionary mandatory flag. The condition is simple and form-based, so a UI policy meets it without code. The dictionary flag is unconditional, the client script adds needless code, and a business rule would not change the form's behavior while the user types.
Objectives 5
Official objectives from the ServiceNow outline, in outline order.
2.1 Create, design, and customize formsLayouts, sections, views and form elements.
- What it means
- Forms are arranged with Form Builder or Form Layout and Form Design tools: sections, field order, formatters such as the activity stream, related lists, and views that present different layouts of the same record to different audiences.
- What to understand
- A view is a named layout of the same table; changing the default view affects everyone who has not been routed to another view. Formatters and related lists add context without new fields. Form changes are configuration files recorded in the current application.
- How it shows up
- A team needs a simplified form for one audience while others keep the full form, and you choose a new view rather than editing the default.
- Common confusion
- Candidates edit the default view for a single audience, changing the form for every user.
2.2 Add/Remove fields from forms and tablesForm layout versus the data dictionary.
- What it means
- Adding a field to a form only places an existing column on a layout; adding it to the table creates a dictionary entry that stores data. Removing a field from a form hides it there, while deleting the column removes the field and its data from the table.
- What to understand
- Dictionary settings such as mandatory, read-only, default value, reference qualifier and choice list apply everywhere the field is used. A dictionary override lets a child table change some of those settings for an inherited field without altering the parent.
- How it shows up
- A scenario asks how to stop showing a field without losing its history, or how a child table can default an inherited field differently.
- Common confusion
- Deleting a column when the requirement only asked to remove it from a form, which destroys stored data.
2.3 Write, test, and debug client-side scripts for desktopClient scripts, UI policies and browser debugging.
- What it means
- Client scripts run in the browser on form events: onLoad, onChange, onSubmit, and onCellEdit for list editing. They use the GlideForm (g_form) and GlideUser (g_user) APIs. UI policies apply conditional mandatory, visible and read-only actions with no code, and can include scripts.
- What to understand
- Use a UI policy first for show, hide, mandatory and read-only rules; use a client script for logic policies cannot express. onSubmit can return false to stop the save. Client scripts should fetch server data with GlideAjax and a client-callable script include, or read values a display business rule placed in g_scratchpad, rather than querying GlideRecord from the browser.
- How it shows up
- A form must react to a field change or validate before submit, and you choose the script type, the API or the best way to get server data.
- Common confusion
- Treating client-side validation as enforcement; imports, web services and list edits can bypass the form.
2.4 Write, test, and debug server-side scriptsBusiness rules, script includes and server debugging.
- What it means
- Business rules run on the server when a record is displayed, queried, inserted, updated or deleted. Timing options are before, after, async and display, and query rules run before a query. Script includes hold reusable server-side code, and UI actions add buttons, links and menu items that can run client or server code.
- What to understand
- Before rules change current before it is saved, so they should not call current.update(). After rules suit changes to other records, async rules move slow work off the user's transaction, and display rules pass data to the client through g_scratchpad. Debug with the Script Debugger for breakpoints, session debug output, and gs.info or gs.debug logging.
- How it shows up
- A requirement names when and on which record logic must run, and you pick the business rule timing or the debugging tool.
- Common confusion
- Calling current.update() in a before business rule, which saves twice and can recurse, instead of letting the save happen.
2.5 Use a Record Producer as an application's UIA catalog-style front end that creates records.
- What it means
- A record producer is a catalog item that creates a record on a target table from the variables a user completes in the Service Catalog or Service Portal. Variables whose names match field names map automatically, and a producer script can set other fields.
- What to understand
- Record producers let requesters create records without seeing or needing rights to the full form. In the producer script, current is the record being created and producer exposes the variables; the platform inserts the record itself, so the script should not call current.insert().
- How it shows up
- Non-technical users must submit requests to a custom table through a simple portal page, and you choose a record producer over form access.
- Common confusion
- Calling current.insert() in the producer script, which creates a duplicate record.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
UI policy
A UI policy applies conditional actions on the client, making fields mandatory, visible or read-only when a condition is true, without scripting.
- Remember
- With Reverse if false selected, the actions undo themselves when the condition stops being true, and UI policies run after client scripts.
- Tested as
- It is the preferred answer for simple conditional form behavior.
- Trap
- Writing an onChange client script to do what a UI policy does with configuration.
-
Client script types
onLoad runs when a form opens, onChange when a specific field changes, onSubmit when the form is saved, and onCellEdit when a list cell is edited.
- Remember
- onChange receives control, oldValue, newValue, isLoading and isTemplate, and most onChange scripts exit early when isLoading is true.
- Tested as
- Questions ask which type fits a timing requirement.
- Trap
- Using onLoad for logic that must react as the user edits a field.
-
GlideAjax
GlideAjax calls a client-callable script include from a client script and returns the answer asynchronously, so the browser does not freeze.
- Remember
- The script include must be client callable and extend AbstractAjaxProcessor; use getXMLAnswer or getXML with a callback.
- Tested as
- It is the best-practice way for a client script to get server data on change.
- Trap
- Running a GlideRecord query or synchronous call from the browser.
-
g_scratchpad
A display business rule can add values to g_scratchpad on the server, which client scripts then read when the form loads.
- Remember
- Display rules run only when the form is loaded, so g_scratchpad cannot respond to later field changes.
- Tested as
- Appears as an efficient way to give onLoad scripts server data.
- Trap
- Choosing g_scratchpad for data that depends on a field the user changes.
-
Business rule timing
Before rules run before the database write, after rules after it, async rules after it in a separate scheduled job, display rules when a form loads, and query rules before a query executes.
- Remember
- Change the current record in before; touch other records in after; move slow, non-blocking work to async.
- Tested as
- One of the most frequently tested facts in the domain.
- Trap
- Updating the current record from an after rule, which forces another save.
-
current and previous
In business rules, current is the record being processed and previous holds field values before the update.
- Remember
- previous is not available in async business rules, and condition methods such as changes() compare current against previous.
- Tested as
- Used in scenarios that act only when a field changes.
- Trap
- Comparing values with previous in an async rule and expecting the pre-update values.
-
setAbortAction
current.setAbortAction(true) in a before business rule stops the database operation, typically with an error message added through gs.addErrorMessage.
- Remember
- It must run before the write, so it belongs in a before rule.
- Tested as
- The server-side way to block an invalid save regardless of entry point.
- Trap
- Using an onSubmit client script alone, which imports and APIs skip.
-
Dictionary override
A dictionary override changes selected properties of an inherited field, such as default value, mandatory, reference qualifier or read-only, for one child table.
- Remember
- The parent table's field is unchanged for other children.
- Tested as
- Appears when a child table needs different behavior for a Task field.
- Trap
- Editing the parent dictionary entry and changing every child table.
-
UI action
A UI action adds a form button, form link, list button or context menu item that runs server code, client code, or both.
- Remember
- Selecting Client runs the onClick function in the browser; a combined script can call gsftSubmit with the action name to continue on the server.
- Tested as
- Questions ask how to add a custom button that updates a record.
- Trap
- Forgetting the Action name, so the server half of a combined UI action never runs.
-
Record producer script
The producer script runs on the server as the record is created, with current for the new record and producer.variable_name for variable values.
- Remember
- The platform performs the insert; calling current.insert() duplicates the record.
- Tested as
- Tested when a producer must set fields that do not match variable names.
- Trap
- Inserting manually and finding two records per submission.
-
Script Debugger
The Script Debugger sets breakpoints and inspects variables in synchronous server-side scripts such as business rules and script includes that run in the developer's own session.
- Remember
- It cannot pause asynchronous scripts or browser code; use logging or the browser's developer tools for those.
- Tested as
- Debugging questions ask which tool fits which script.
- Trap
- Expecting breakpoints in a client script or an async business rule.
-
Form view
A view is an alternative layout of the same table's form or list for a particular audience or context.
- Remember
- View rules can route users to a view automatically by condition, device or role.
- Tested as
- The right answer when one audience needs a different form.
- Trap
- Changing the default view for everyone to satisfy one group.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
UI policy vs. client script vs. data policy vs. before business rule
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| UI policy | Configured conditional mandatory, visible or read-only actions on forms | No code; runs only in the browser | Expecting it to block an import or REST insert |
| Client script | Browser JavaScript on load, change, submit or cell edit | Handles logic policies cannot, still bypassable | Using it where a UI policy suffices |
| Data policy | Configured mandatory or read-only rules enforced on the server | Applies to imports, web services and forms | Forgetting it cannot hide fields |
| Before business rule | Server script before the database write | Can change values or abort the save for every entry point | Calling current.update() inside it |
Business rule timings
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Before | Runs before the record is written | Modify current; abort the save | Adding current.update() |
| After | Runs after the write, in the same transaction | Update related records; user waits | Changing current here and saving again |
| Async | Runs after the write as a scheduled job | User does not wait; good for slow work and integrations | Relying on previous values |
| Display | Runs when a form loads, before it reaches the browser | Fills g_scratchpad for client scripts | Expecting it to rerun on field change |
Remove from form vs. delete column vs. dictionary override
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Remove from form | Takes the field off one layout or view | Data and field remain | Thinking data was deleted |
| Delete column | Removes the dictionary entry from the table | Field and its stored data are gone | Using it to tidy a form |
| Dictionary override | Child-table change to an inherited field's settings | Parent and sibling tables unaffected | Editing the parent field instead |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Client-side check as enforcement
- What candidates pick
- An onSubmit client script that blocks saves with an invalid date.
- Why it looks right
- It gives instant feedback and works when testing on the form.
- Why it's wrong
- Imports, REST calls and some list edits never run form scripts, so the rule is not enforced.
Clue to watch for The requirement says the rule must apply however records are created or updated.
-
update() in a before rule
- What candidates pick
- A before business rule that sets a field and then calls current.update().
- Why it looks right
- Developers coming from other platforms expect to save explicitly.
- Why it's wrong
- The before rule's changes are saved by the pending write; calling update triggers another save and can rerun business rules.
Clue to watch for The rule changes fields on the same record being saved.
-
Display rule for live changes
- What candidates pick
- A display business rule with g_scratchpad to fetch the caller's location when the caller changes.
- Why it looks right
- g_scratchpad is the efficient, well-known way to send server data to the form.
- Why it's wrong
- Display rules run once when the form loads, so they cannot react to a field changed afterward; GlideAjax can.
Clue to watch for Data is needed after a user changes a field, not at load.
-
After rule for the current record
- What candidates pick
- An after business rule to set a field on the record being saved.
- Why it looks right
- After rules feel safer because the record already exists.
- Why it's wrong
- Changing current in an after rule needs another update call and another save cycle; a before rule sets it at no cost.
Clue to watch for The field to change belongs to the same record that triggered the rule.
-
Edit the default view
- What candidates pick
- Remove fields from the default form layout so field technicians get a simpler form.
- Why it looks right
- It is the quickest visible change.
- Why it's wrong
- Every user of the default view loses those fields; a separate view, optionally applied by a view rule, serves one audience.
Clue to watch for Only one group of users needs the different layout.
-
Give requesters form access
- What candidates pick
- Grant requesters write access to the custom table so they can submit records.
- Why it looks right
- It uses the forms the developer already built.
- Why it's wrong
- A record producer lets them submit through the catalog or portal without rights to the full form or table.
Clue to watch for The users are non-technical requesters, and the scenario mentions the portal or a simple request page.
Answer framework
When a Domain 2 question asks where to put form or record logic, decide in this order.
- Decide whether the rule must hold for every entry point, including imports and APIs, or only for users on the form.
- For always-enforced rules, use a data policy or a before business rule; for form-only rules, start with a UI policy.
- Use a client script only when the form logic needs calculations, messages or server data that a UI policy cannot express.
- When client code needs server data after load, call a client-callable script include through GlideAjax; at load, use a display rule and g_scratchpad.
- Pick the business rule timing by target: before for the current record, after for other records, async for slow work, then debug with the matching tool.
Practice question
Want more like this? The ServiceNow CAD practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Work through this domain in the order a record is touched: the form, then the browser, then the server. Begin in a personal developer instance by creating a second view of a custom form, adding a field to the form and separately to the table, and setting a dictionary override on a child table. That makes the layout-versus-dictionary distinction concrete.
Next, build the same requirement three ways: as a UI policy, as an onChange client script and as a before business rule. Then insert a record with an import or a background script and watch which versions still apply. This one exercise answers a large share of scenario questions.
Give extra time to business rule timing, the most commonly underestimated area. Write before, after, async and display rules that each log a message, and note what current and previous contain in each. Build one GlideAjax call and one g_scratchpad example, and set a breakpoint in the Script Debugger.
Finish with a record producer that targets your custom table, then practice timed questions that ask you to choose the layer. For each miss, write down whether the error was about entry point, timing or the client-server boundary.
FAQ
How much of the ServiceNow CAD exam is Application User Interface?
The domain is 20% of the exam. As a planning estimate, that is about 12 of the 60 questions, though ServiceNow does not publish per-domain counts.
When should I use a UI policy instead of a client script?
Use a UI policy for conditional mandatory, visible or read-only behavior, since it needs no code and reverses cleanly. Use a client script when you need logic, messages or server data that a policy cannot express.
Why is GlideRecord in a client script discouraged?
It makes the browser query the server in a way that can block the form and send more data than needed. GlideAjax with a client-callable script include returns only the answer, asynchronously.
What is the difference between before and after business rules?
A before rule runs before the write, so it can change the current record or abort the save without calling update. An after rule runs once the write is done and suits updates to related records.
Does a UI policy stop bad data from an import?
No. UI policies and client scripts run only on forms. Use a data policy or a before business rule to enforce rules for imports and web services.
What makes a record producer a good application UI?
It gives requesters a simple catalog or portal page that creates a record on your table, without exposing the full form or requiring write access to it.
How does this domain relate to security?
Hiding or making fields read-only on a form changes the experience, not the data rights. Domain 3 covers access controls, which are what actually restrict reading and writing.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have compared form layouts, dictionary settings, UI policies, client scripts, business rules and record producers. Check whether you can pick the right layer and timing under exam pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ServiceNow CAD AI tutor Get any concept explained your way