Free CAD Practice Test

Client-side scripts execute in the browser, so debugging must use APIs that run on the client.
• gform.addInfoMessage() inserts an informational banner at the top of the form, allowing a script writer to surface variable values or execution points directly to the user interface.
• jslog() writes messages to the JavaScript Log window (opened from Application Navigator → System Diagnostics → JavaScript Log), giving real-time diagnostic output while the script runs in the browser. Both functions are explicitly documented for client-side troubleshooting and do not require a round-trip to the server.

A. gs.addErrorMessage() – GlideSystem API; executes only in server-side scripts (Business Rules, Script Includes), unavailable in the browser.
C. gs.log() – Another GlideSystem (server-side) logging method; cannot be called from Client Scripts or UI Policies.

1. ServiceNow Developer Site, “gform.addInfoMessage(message)” – Client-side API description and example (Utah release), Section: gform API, paragraph 1.

2. ServiceNow Product Documentation, “JavaScript Log” – Debugging client-side code; states “Use jslog() to output messages to this log.” (Rome release)

3. ServiceNow Docs, “Debugging client scripts” – Notes that gs. methods are server-side only, unsuitable for client debugging (Paris release, para. 2).

ServiceNow provides the Annotation field type specifically so designers can embed static, read-only text (and optional images or HTML) directly on a form. Because an annotation is treated as a field, it appears in the normal tab order, moves with the form layout, and requires no scripting or navigation outside the record. ServiceNow documentation and the official CAD courseware cite annotations as the recommended, lightweight method for presenting user instructions or guidance on a form.

B. Related links open external pages; users must leave the record, so guidance is not immediately visible and is discouraged for inline instructions.
C. Context-menu UI Actions hide instructions behind a right-click, making them non-discoverable and intended for actions, not help text.
D. A read-only populated field stores data unnecessarily and clutters the table; it is not meant for instructional content.

1. ServiceNow Product Documentation – “Annotation field type” in Field Type Reference, UI Framework, para. 1-3 (Rome release docs).

2. ServiceNow Product Documentation – “Add instructional text to a form using an annotation,” Configure > Forms > Annotations, steps 1-2.

3. ServiceNow Certified Application Developer Courseware (Now Learning) – Module “Create and Design Application Forms,” section “Best practices: provide help with Annotation fields,” slide 7.

4. ServiceNow Developer Site – Form Design Guide, “Use Annotation to supply inline help,” rev June 2023, p. 2.

A Record Producer is displayed as a catalog item, so catalog-item features such as an image banner (graphics) are allowed. Its user interface is built from Service Catalog variables whose “Question” text, not the database field label, is shown to the requester. Because Record Producers are catalog items, they support Catalog Client Scripts and Catalog UI Policies, letting developers script field behavior (hide, populate, validate, etc.). Scripting is therefore optional, and although a Request Item (screqitem) is generated, the primary record is written to whatever target table the designer specifies (e.g., Incident), not exclusively to screqitem.

B. Creates an screqitem plus the target-table record (e.g., Incident); therefore not “all records” go only to screqitem.
D. Scripting is optional; a record producer can work with only variable mapping and no script.

1. ServiceNow Product Documentation, “Create or modify a record producer” → Section: Record producer form > Image field (docs.servicenow.com, Orlando release).

2. ServiceNow Product Documentation, “Record producer variables” → Paragraph: “The question text… is displayed to users instead of the field label.”

3. ServiceNow Product Documentation, “Catalog client scripts” → Section: Applies to catalog items and record producers (Madrid & later).

4. ServiceNow Product Documentation, “Request and request item records created by record producers” → Paragraph: “Submitting a record producer creates a Request [screquest], a Request Item [screqitem], and the target table record such as Incident.”

In ServiceNow, a child table created by extending another automatically inherits every column of the parent while also containing any new columns that are defined on the child. Because Exportitem extends Item, it receives ItemName and ItemQty from Item, and additionally holds its own column, ItemCountry. Therefore the set of available columns is ItemName, ItemQty, and ItemCountry.

A. Number is not defined on either Item or Exportitem; only System fields are auto-added, not an arbitrary “Number” field.
B. Omits the child’s unique column, ItemCountry, which is always present on the child table.
D. Ignores inherited parent columns; extension always includes all parent fields.

1. ServiceNow Product Documentation – “Extending a table”, Paris release, Table Administration → Table extensions: “A table that extends another table inherits all of its parent table’s columns and may also include additional columns defined on the child.” (doc ID: SN-DOC-PAR-TA-EXT, para. 2).

2. ServiceNow Developer Site – Data Model: “Child tables have access to every field on the parent plus any new fields created specifically on the child table.” (URL: https://developer.servicenow.com/ → Data Model → Table Extension, section ‘Inheritance’, ¶1).

ServiceNow provides a “one-click” wizard that automatically builds a Record Producer and pre-creates an entry for every column on a table. You reach this wizard by opening the table record (System Definition → Tables) and selecting the related link Add to Service Catalog. No manual variable creation is required, making it the quickest configuration path.

A. Categories organise items but do not generate Record Producers; you must still create the producer separately, so it is slower.
B. The Record Producer module opens a blank producer; all variables and mappings have to be added manually, making it more time-consuming.
D. Form header menus do not include a “Create Record Producer” option; even if scripted, it would lack the automatic variable generation the table wizard provides.

1. ServiceNow Product Documentation, “Create a record producer using a table,” Rome release, doc ID: servicenow.recordproducer.table, Step 2 (“Click Add to Service Catalog related link”).

2. ServiceNow Developer Site, “Record Producer Best Practices,” Section “Generate from table,” para 1-2, accessed 2024-02-13.

The Impersonate User function is exposed in the banner-frame drop-down that shows the current user’s name and avatar. This drop-down is officially called the User Menu; administrators open it and choose “Impersonate User” to assume another user’s security context. Neither the Application Navigator, Content Frame, nor individual modules contain this global UI action.

B. Content Frame – Displays record or form content; contains no banner-frame controls such as Impersonate User.
C. Application Navigator – Lists applications/modules; offers filter and favorites only, not Impersonate User.
D. Module – Launches specific functionality but does not include user-level banner actions like impersonation.

1. ServiceNow Product Documentation, “Impersonate a user,” Rome UI16 Navigation, section: User menu → Impersonate User (docs.servicenow.com; paragraph 1).

2. ServiceNow Product Documentation, “Navigate the banner frame,” UI16 Interface Guide, table: User Menu options, row “Impersonate User” (docs.servicenow.com; UI16BannerFrame.pdf, p.3).

3. ServiceNow Certified System Administrator Courseware, Module 2 “User Interface,” slide 16: Banner > User Menu > Impersonate (ServiceNow Training, 2021).

In ServiceNow, a Reference field establishes a relationship to another table by storing the sysid of a record in that table and displaying its display value. When added to a form, the field automatically produces a slush-bucket or auto-complete lookup so users can query and select records from the referenced table. No other field type enables live querying of another table in this manner; Phone Number, String, and Date merely capture literal values, not foreign-key links.

B. Phone Number fields hold formatted telephone data; they do not point to external tables.
C. String fields store free-text; they lack foreign-key functionality to query other tables.
D. Date fields capture date/time values only; they cannot reference or retrieve external records.

1. ServiceNow Product Documentation - “System Dictionary: Field Types – Reference,” Quebec release, docs.servicenow.com → Platform > Foundation Data > Tables and Columns > Reference fields (para. 1-3).

2. ServiceNow Developer Site – “Create a Reference field,” Module: Data Model - Tables, Section “How Reference fields work” (steps 1-2, example walkthrough).

Service Level Agreements (SLAs) in ServiceNow define a target duration (start, pause, stop) for a task and attach a running timer that shows elapsed and remaining business time. The platform continually evaluates the SLA definition against the task record and updates the “SLA percentage,” “time left,” and related fields, enabling process owners to monitor whether the task is progressing within the contracted or internally allotted window.

A. Task Escalation Clock – Not an out-of-box ServiceNow feature; escalation is handled through SLA breach workflows or task escalation rules, not a separate “clock.”
B. Business Time Remaining – Only a display field created by an SLA, not a standalone feature that drives tracking logic.
C. Inactivity Monitor – Triggers events after user-defined idle periods, measuring silence rather than total open time to completion.
E. Response Time Clock – Non-existent native object; first-response targets are again managed by SLA definitions with “response” type goals.

1. ServiceNow Product Docs, “Service Level Agreements – Overview,” Service Level Management module, para. 1-3 (Tokyo release): “Use an SLA definition to track the amount of time a task has been open and ensure it is completed within a specified time.”

2. ServiceNow Courseware, “ServiceNow Fundamentals – Module 9: Service Level Agreements,” p. 3, step 1: “SLAs attach timers to tasks so fulfillment teams can see elapsed and remaining business time.”

3. ServiceNow Product Docs, “Create an SLA Definition,” Section: ‘Duration’ fields (Tokyo): explains start, pause, and stop conditions that calculate elapsed time.

During ACL evaluation ServiceNow uses a fixed sequence to avoid unnecessary processing.
1) The platform first verifies that the user possesses at least one of the roles listed in the rule.
2) If the role test passes, any Condition specified on the rule is evaluated.
3) Only when both the role and condition checks succeed is the Script block executed. Access-control debugging output is produced in this same order: Roles → Conditions → Script, indicating whether each element allowed or denied access.

A. Lists Conditions before Roles and Script, reversing the documented first step.
B. Places Script first; scripts never run until roles and conditions succeed.
C. Starts with Conditions, not Roles, contradicting the documented sequence.

1. ServiceNow Documentation, “Access Control rules”, sub-heading “Evaluation order” (Utah release): “The system checks required roles first, then evaluates the condition, and finally runs the script.”

2. ServiceNow Documentation, “Debugging Access Controls”, Step 6, sample log lines (Utah): shows output sequence “Role: true/false … Condition: true/false … Script: true/false”.

3. ServiceNow Documentation, “Create an access control” > “Access control components”: roles evaluated before other components.

4. ServiceNow Platform Implementation Courseware (ServiceNow EDU-CAD-PLT-2023), Module 4 “Security”: Slide 27 “ACL Processing Order – Roles → Condition → Script”.

In Flow Designer, a spoke is the formal term for a scoped application whose primary contents are Flow Designer resources (actions, subflows, and any supporting artifacts). When a developer packages new flow actions inside their own scope, that package is therefore called a “spoke.”

A. Bundle – Generic packaging term; ServiceNow does not name a Flow Designer action-containing scoped application a “bundle.”
B. Row – No Flow Designer or application construct with this name exists.
C. Action – An individual Flow Designer building block, not the overall scoped application that contains several actions/subflows.

1. ServiceNow Documentation, “Spokes – About spokes,” Utah release, first paragraph: “A spoke is a scoped application that contains Flow Designer actions, subflows, and supporting artifacts.”

2. ServiceNow Developer Site, Learning Plan “Creating a Spoke,” Vancouver module 2, Slide 1: “Spokes are packaged scoped applications used to group and distribute Flow Designer actions.”

3. ServiceNow Product Documentation, Flow Designer Fundamentals PDF, Sect. 3.2 “Extending Flow Designer,” p. 27: “Developers publish custom actions inside spokes—scoped applications dedicated to Flow Designer content.”