Part 6 Full Quiz

B is correct. This is the critical UI Policy trap on the CSA exam. UI Policies are client-side JavaScript rules — they execute only in the user's browser during normal form interaction. They have zero enforcement power over API calls, import set transforms, background scripts, or any data submission that bypasses the browser form. To truly enforce data integrity regardless of how data enters the system, a Before Business Rule (server-side) must be used for validation. A is wrong — UI Policies apply across the main platform. C is a distractor. D is the exact opposite of the truth.

B is correct. A UI Policy is specifically designed to dynamically change field characteristics (Mandatory, Read-Only, Visible/Hidden) on a form based on a condition — no scripting required. A UI Policy Action defines what happens to a specific field when the policy condition is true. The combination of one UI Policy (condition: VIP Customer is checked) with two UI Policy Actions (Priority = Read-Only; Escalation Reason = Mandatory) is the exact right tool. A Business Rule (A) runs server-side and cannot directly control field UI characteristics. An ACL (C) controls security access, not form behavior. Flow Designer (D) automates process steps, not real-time form field states.

C is correct. A UI Action creates interactive controls on forms or lists — form buttons, list banner buttons, context menu items, and links — that execute JavaScript when clicked. UI Actions are the standard way to add custom action buttons to ServiceNow forms. A UI Policy (A) changes field characteristics based on conditions; it does not create buttons. A Client Script with onSubmit (B) runs when the form is submitted, not when a specific custom button is clicked. A Display Business Rule (D) runs before the form loads to pass server data to the client — it does not create buttons.

B is correct. A Before Business Rule executes after the user clicks Save but BEFORE the record is written to the database. This timing is critical for validation: if validation fails, the developer can call current.setAbortAction(true) and gs.addErrorMessage() to prevent the database write and return an error to the user's form. An After Business Rule (A) executes after the database commit — the record is already saved, so it is too late to prevent it. C is wrong — it fires after Save is clicked, not before. D is wrong — Async Business Rules run in the background and cannot block saves, but After Business Rules can display messages.

B is correct. This is one of the most dangerous and frequently tested Business Rule traps. Calling current.update() inside a Before or After Business Rule on the same table triggers that Business Rule again (because an update event fires again), which calls current.update() again, which fires the rule again — creating an infinite recursion loop. This can crash or severely degrade the instance. The correct approach is to simply set field values directly on the current object (e.g., current.priority = 1) in a Before Business Rule, and the platform handles saving them as part of the original transaction. A is wrong — current.update() is a valid method, just dangerous here. C is wrong — it works in server-side scripts. D is wrong — no special role is required.

B is correct. g_scratchpad is the shared bridge between Display Business Rules (server-side, runs before form is sent to the browser) and Client Scripts (client-side, runs in the browser). The Display Business Rule sets values on g_scratchpad (e.g., g_scratchpad.riskScore = 87), and Client Scripts can read those values without any additional server round-trip (e.g., var score = g_scratchpad.riskScore). A is wrong — g_form_data is not a ServiceNow standard object. C describes GlideAjax, which requires a round-trip and adds latency. D is wrong — Client Scripts cannot read the sys_log table.

C is correct. The onChange Client Script type fires each time a specific field value changes on the form — exactly the trigger needed here. The developer specifies the field name to watch (Category) and the script runs automatically when the user changes it. onLoad (A) runs once when the form initially loads — it does not react to field changes. onSubmit (B) runs when the user clicks Save — it fires at submit time, not during field interaction. onCellEdit (D) fires when a user edits a cell in a list view, not on a form field.

B is correct. This is a critical client script performance trap. JavaScript in the browser is single-threaded. A synchronous GlideRecord query from a Client Script makes a blocking server round-trip — the browser's UI thread is completely frozen while waiting for the server response, making the form unresponsive. The correct alternatives are: (1) use g_scratchpad populated by a Display Business Rule (no round-trip), or (2) use GlideAjax (asynchronous — provides a callback function, does not freeze the UI). A is wrong — GlideRecord is technically available in client scripts but should never be used synchronously. C is a distractor. D is wrong — a syntax error would show a console error, not a freeze.

B is correct. g_user is the client-side JavaScript object that provides information about the currently logged-in user. It includes methods like g_user.hasRole('itil') to check role membership, and properties like g_user.userID and g_user.userName. g_form (A) is the client-side class for controlling form fields (getValue, setValue, setMandatory, setVisible) — it does not provide user information. GlideSession (C) is a server-side API not available in Client Scripts. gs.hasRole() (D) is also a server-side GlideSystem method, not available client-side.

B is correct. A UI Script is a reusable client-side JavaScript library that can be loaded and called by Client Scripts, UI Actions, and Service Portal widgets. It is the correct tool for shared client-side utility functions. A Display Business Rule (A) runs server-side before the form loads — it cannot contain reusable client JavaScript. A Script Include (C) is a server-side reusable JavaScript library — it runs on the server and is not directly accessible to client scripts (though it can be used via GlideAjax). A Scheduled Job (D) runs background server-side tasks on a schedule.

B is correct. Flow Designer is the modern ServiceNow tool designed for codeless multi-step process automation. It provides visual triggers (record created), actions (Create Task, Send Email), wait conditions (Wait 24 hours), decision branches (Is task complete?), and escalation actions — all without writing code. Business Rules (A) are single-event server-side scripts, not designed for multi-step flows with waits and branching. Client Scripts (C) are browser-side and cannot orchestrate server-side multi-step processes. ACLs (D) control security access, not process automation.

B is correct. A Subflow is a reusable flow block that can be called (invoked) from within one or more parent flows. It encapsulates a set of actions — in this case the approval logic — that can be maintained in one place and reused across multiple flows. Changing the approval logic in the Subflow automatically updates all parent flows that call it. A Spoke (A) is a pre-built IntegrationHub package for a third-party service, not a reusable internal flow block. Async Business Rule (C) runs a background script on a database event — it cannot be called from Flow Designer as a reusable step. UI Script (D) is a client-side JavaScript library, not a flow component.

B is correct. As of the Zurich release, the Legacy Workflow Editor is deprecated for new work. All new process automations should be built in Flow Designer, which provides a modern codeless interface, better performance, built-in IntegrationHub integration, and active development investment. Existing legacy workflows continue to run but should be migrated to Flow Designer over time. A is the trap — the colleague is wrong. C is wrong — ServiceNow explicitly directs new work to Flow Designer. D is wrong — Flow Designer supports complex multi-step flows with conditions, approvals, subflows, and waits.

C is correct. An Async Business Rule queues a background job that runs after the main transaction completes, without blocking the user's browser. This is ideal for updating related records in another table — the user sees their Incident saved immediately and can navigate away while the background update processes. An After Business Rule (B) runs synchronously after the database save — it still holds the server response until it completes, causing the browser to wait. Before (A) runs before the save and would be wrong for post-save related updates. Display (D) runs before the form loads and cannot react to save events.

B is correct. A common UI Policy misconfiguration trap involves the "Reverse if false" option and condition logic. If the policy condition is "user is in Management group = true → show the field" but "Reverse if false" is also checked, then when the condition is false (non-managers) the reverse action runs — hiding the field. However, if the condition or the action is inverted (hide instead of show), even managers would have the field hidden. Carefully checking the condition logic and whether Reverse if false is set correctly resolves most UI Policy visibility issues. A is wrong — UI Policies can check group membership via condition scripts. C is wrong — UI Policies apply to all users based on the condition. D is wrong — visibility is not controlled by security_admin.