Part 3 Full Quiz

B is correct. This is a critical exam trap. Even if a notification is perfectly configured, it will silently fail to deliver if the recipient has email notifications disabled in their user profile preferences (sys_user record → Notification field set to "Disabled"). This is a common real-world issue that affects individual users while other users receive the notification normally. Option A is wrong — notifications don't require security_admin. Option C is wrong — Incident is a core table that fully supports notifications. Option D would affect ALL email notifications across the instance, not just one user.

B is correct. gs.eventQueue() is the standard ServiceNow server-side JavaScript method used to add an event to the event queue. The event queue is processed asynchronously and fires any notifications registered against that event in the Event Registry (sysevent_register). The signature is: gs.eventQueue(event_name, GlideRecord, param1, param2). The current GlideRecord provides context. Options A, C, and D use method names that do not exist in ServiceNow's GlideSystem or GlideRecord APIs.

B is correct. ServiceNow email notifications (sysevent_email_action) are structured around three tabs/sections: When to send (the triggering conditions — which event, table, and filter conditions must be met), Who will receive (the recipient logic — users, groups, event parameters), and What it will contain (the message content — subject line, body using HTML and variables). Memorise these three as "When / Who / What" — they map directly to the three tabs on the notification record and are a staple CSA exam question.

C is correct. The ServiceNow Report Designer follows a 4-step wizard in this exact sequence: 1. Data (choose the source table and apply filter conditions), 2. Type (select the report type: Bar, Pie, List, Trend, etc.), 3. Configure (set grouping fields, aggregations, axis labels), 4. Style (colours, chart size, title formatting). The order matters for the exam: Data → Type → Configure → Style. Choosing the data source before the chart type makes logical sense — you need to know what data you have before choosing how to display it.

B is correct. This is a critical exam trap about the distinction between report sharing and data access. Report sharing (Me / Everyone / Groups and Users) only controls who can see the report widget on the dashboard. It does NOT grant access to the underlying records. When a user drills down into a report segment, ServiceNow queries the actual source table — and at that point, the user's ACLs determine whether they can see those records. If their role doesn't permit reading that table, they get an access error even though the aggregate chart was visible. Always remember: sharing ≠ data access.

D is correct. An Interactive Filter is a special widget that can be added to a dashboard tab. When a user changes the Interactive Filter value (e.g., selects "Last 30 days"), it dynamically applies that filter condition to all reports on the same dashboard tab simultaneously. This eliminates the need to edit individual report conditions. Interactive Filters are commonly used for date ranges, assignment groups, or priority levels. "Global Filter" (A), "Dashboard Condition" (B), and "Report Sync" (C) are not standard ServiceNow dashboard features.

B is correct. Knowledge Base access is controlled by User Criteria records — these are separate from ACLs and roles. Each Knowledge Base has two User Criteria lists: "Can Read" (who can view published articles) and "Can Contribute" (who can author/edit articles). User Criteria can match by users, groups, roles, companies, or departments. This is a different mechanism from the ACL system that controls table/field access. Roles and ACLs (A, C) alone do not control KB access. Option D is wrong — KBs can absolutely be restricted.

B is correct. In ServiceNow Knowledge Management, "Cannot Read" takes precedence over "Can Read". If a user matches any "Cannot Read" User Criteria on a Knowledge Base, they are denied access regardless of whether they also match a "Can Read" User Criteria. This allows organisations to create precise exclusions — for example, open a KB to all employees but explicitly exclude contractors who may technically also match an "employee" group. This deny-wins logic is different from many other access control systems and is specifically tested on the CSA exam.

A is correct. The Knowledge Article lifecycle in ServiceNow follows these exact states: Draft (author is writing the article, not visible to end users) → Review (submitted for approval, under review by knowledge manager) → Published (approved and visible to users with Can Read access) → Retired (removed from active use, no longer visible but preserved in the database for history). Memorise the four stages: Draft → Review → Published → Retired. These are the exact state names used in the ServiceNow Knowledge workflow.

B is correct. The Service Catalog hierarchy has three levels: REQ (sc_request) — the top-level container record created when a user submits a cart; RITM (sc_req_item) — one record per catalog item ordered within the REQ; SCTASK (sc_task) — optional sub-tasks created within a RITM for individual work steps. The RITM is the primary record that fulfillers work on to deliver the service. Option A (REQ) is the requester's umbrella record. Option C (SCTASK) is for sub-tasks within a RITM. Option D is wrong — catalog requests do NOT automatically create Incidents (that would be a Record Producer, which is a different catalog type).

C is correct. A Record Producer is a special type of catalog item that, upon submission, creates a record on a specified table (Incident, Change, Problem, or any custom table) instead of creating the standard RITM. This gives users a user-friendly, catalog-style interface while the back-end creates the correct record type. This is commonly used to provide "Report an Incident" or "Submit a Change" buttons in the Service Portal. A standard Catalog Item (A) always creates a REQ/RITM structure. An Order Guide (B) bundles multiple standard catalog items. Content Item (D) is informational only.

B is correct. A Variable Set is a reusable container of Catalog Variables that can be attached to multiple catalog items. You define the 5 variables once in the Variable Set, then attach it to all 12 catalog items. If you need to update any of the 5 questions later, you edit the Variable Set once and the change propagates to all 12 items automatically. This is a major efficiency gain over maintaining variables individually. "Variable Template" (A) is not a standard ServiceNow term. Order Guide (C) is for bundling items at checkout, not sharing variables. "Global Variable" (D) does not exist as a ServiceNow catalog feature.

B is correct. This is a critical Variable Set trap. Because the Variable Set is a shared record, any change made to it (adding variables, changing field types, updating labels, reordering) immediately affects all catalog items that reference it. This is both a powerful feature (one change updates everywhere) and a potential risk (an unintended change breaks every item using the set). Admins must be extremely careful when editing shared Variable Sets in production. There is no selective application — it's all-or-nothing. If item-specific customisation is needed, use individual variables on that specific catalog item instead.

D is correct. An Order Guide is a special catalog item type that bundles multiple standard catalog items together into a single checkout experience. When a user orders an Order Guide, they complete one set of questions and ServiceNow automatically orders all the bundled items, creating separate RITMs for each. This is perfect for complex onboarding scenarios where multiple services need to be provisioned together. A Record Producer (A) creates task records, not bundles. A Variable Set (B) is for sharing variables across items. A Catalog Category (C) is just an organisational folder for grouping items in the catalog UI.

B is correct. Knowledge Categories are hierarchical folder-like groupings within a Knowledge Base. Each KB can have multiple categories, and categories can be nested (sub-categories). When an author creates an article, they assign it to a category. Users browsing the Knowledge Base see the category structure and can navigate articles by topic. Categories can also be nested — for example, "Software" can have sub-categories "Microsoft Office" and "Adobe". "Knowledge Tag" (A) is not a standard ServiceNow term. "Knowledge Group" (C) and "Knowledge Folder" (D) are not the correct ServiceNow terms for this feature.

B is correct. The Event Registry (table: sysevent_register) is where all valid event names are registered in ServiceNow. Before a notification can subscribe to an event, that event name must exist in the Event Registry. When a Business Rule fires gs.eventQueue('incident.escalated', current), ServiceNow looks up 'incident.escalated' in sysevent_register, then checks sysevent_email_action (Notifications) for any notifications configured to send on that event. The flow is: Business Rule → gs.eventQueue() → Event Registry (sysevent_register) → Notification (sysevent_email_action). sys_trigger (A) handles scheduled jobs, not event routing. syslog (D) is for system logging, not notification routing.