Certified Application Developer - ServiceNow Practice Test 2026
The CAD exam is where scripting confidence gets tested. Business rules, client scripts, UI policies, Flow Designer, scoped apps, and security all show up here. These 325 questions come with sourced explanations so you can see why the platform behaves the way it does.
What's included
- 325 developer-focused questions on scripting, Flow Designer, and scoped apps
- Every answer links to the ServiceNow doc page behind it
- Per-option reasoning shows why each distractor falls apart
- Built around Zurich-era behavior and the 2026 exam specs
- Yours for the long haul. Updates are included.
- Published by someone who passed all 18 ServiceNow exams on the first attempt
- Udemy backs it with a 30-day refund window
15 Free Preview Questions
Answer 5 questions free. Enter your email to continue through question 15. The full course has 325 questions on Udemy.
- ADrag a section container from the Field Types tab.
- BDrag a section container from the Fields tab.
- CClick the Add Section (+) button next to an existing section label.
- DUse a UI Policy to dynamically generate a new section on load.
Show full explanation
Correct Answer
C. Click the Add Section (+) button next to an existing section label.
Source
ServiceNow Zurich - Form Designer
If the link fails, search Google for: ServiceNow Zurich Form Designer add section
Expert Explanation
The Form Designer is the primary tool for modifying form layouts in ServiceNow. When a developer needs to add a new section to organize fields, they use the Add Section (+) button located next to existing section labels in the form layout. This button inserts a new collapsible section that can then be named and populated with fields by dragging them from the Fields tab.
Key points about Form Designer sections:
- Sections are structural containers that group related fields together on a form
- The (+) button appears inline with section headers, making it contextual and intuitive
- New sections can be repositioned by dragging the section header to a different location
- Each section can have its own caption, column layout (1, 2, or 3 columns), and visibility rules
Why the Others Are Wrong
- A. Drag from Field Types tab - The Field Types tab contains data type options for creating new fields (String, Integer, Date, etc.), not layout containers. Sections are not field types.
- B. Drag from Fields tab - The Fields tab lists table columns that can be placed on the form. It does not contain structural elements like sections. Fields go inside sections, not the other way around.
- D. UI Policy - UI Policies control runtime behavior (show/hide, mandatory, read-only) of existing form elements. They cannot create new sections dynamically - they can only toggle visibility of sections already defined in the layout.
Memory Tip
Think of it like adding a new chapter to a book: you do not drag a chapter from a list of word types - you click the "+" button to insert a new chapter heading right where you need it. Section = structure, Field = content.
Real-World Example
A ServiceNow developer at a healthcare company needs to add a "Clinical Details" section to the Incident form for medical device issues. She opens Form Designer, clicks the (+) button next to the existing "Notes" section label, names the new section "Clinical Details," and then drags fields like "Device Serial Number" and "Patient Impact" into it. The entire process takes under 2 minutes without writing any code.
- ATracking only
- BEnforcing only
- CBoth Tracking and Enforcing
Show full explanation
Correct Answer
C. Both Tracking and Enforcing
Source
ServiceNow Zurich - Runtime Access Tracking
If the link fails, search Google for: ServiceNow Zurich Runtime Access Tracking cross-scope
Expert Explanation
Runtime Access Tracking is a critical governance feature for scoped applications in ServiceNow. It monitors and controls how scripts in one application scope interact with resources (tables, scripts, APIs) belonging to another scope.
The two settings work together:
- Tracking - Monitors cross-scope access attempts and logs them. When combined with Enforcing, it causes the platform to automatically generate records in the Application Cross-Scope Access table (sys_scope_privilege).
- Enforcing - Actively blocks unauthorized cross-scope access. When combined with Tracking, access requests that are not yet approved will be recorded and denied until an administrator grants permission.
When both are enabled, every cross-scope access attempt triggers automatic record creation in the Cross-Scope Access table. Administrators can then review these records and set the Status to "Allowed" or "Denied" to control the access going forward.
Why the Others Are Wrong
- A. Tracking only - Tracking alone writes to system logs but does not automatically populate the Application Cross-Scope Access table with actionable records. It observes but does not create the governance workflow.
- B. Enforcing only - Enforcing alone blocks access but without Tracking enabled alongside it, the full automatic record-creation pipeline for all access requests is not activated. Both settings must be active for the complete behavior described in the question.
Memory Tip
Think of a security camera (Tracking) and a locked door (Enforcing). The camera alone just watches. The lock alone just blocks. But when you have both, the system automatically generates a visitor log entry (Cross-Scope Access record) every time someone tries the door.
Real-World Example
A developer at a financial services firm builds a custom Loan Processing app (x_loan scope) that needs to read data from the ITSM Incident table (in global scope). With both Tracking and Enforcing enabled, when the Loan app's Business Rule tries to query the Incident table, ServiceNow automatically creates a record in the Cross-Scope Access table showing "x_loan requesting read access to incident." The platform admin reviews the request and approves it, allowing the integration to proceed securely.
- AIntegration Hub
- BAI Control Tower
- CMachine Learning Framework
- DPredictive Intelligence
Show full explanation
Correct Answer
B. AI Control Tower
Source
ServiceNow Zurich - AI Control Tower
If the link fails, search Google for: ServiceNow Zurich AI Control Tower governance management
Expert Explanation
AI Control Tower is ServiceNow's purpose-built application for enterprise AI governance and management. As organizations deploy Generative AI capabilities on the Now Platform and beyond, AI Control Tower is the central command center that connects four critical pillars:
- Strategy - Aligns AI initiatives with business goals and objectives
- Governance - Enforces policies, compliance, and ethical guidelines for AI usage
- Management - Provides operational oversight of AI models, agents, and deployments
- Performance - Tracks metrics, ROI, and effectiveness of AI implementations
This application is especially important as enterprises scale their use of Now Assist (ServiceNow's Generative AI) and integrate third-party AI tools, ensuring that all AI activity is visible, governed, and aligned with organizational strategy.
Why the Others Are Wrong
- A. Integration Hub - Focused on system-to-system integrations using spokes and Flow Designer actions. It connects systems, not AI strategy to governance.
- C. Machine Learning Framework - A developer toolkit for building and training ML models within ServiceNow. It is a technical building block, not a strategic governance application.
- D. Predictive Intelligence - Applies ML to automate specific tasks like incident categorization and case routing. It is an AI consumer, not an AI governance platform.
Memory Tip
Think of an airport Control Tower - it does not fly planes (that is Predictive Intelligence), build planes (that is ML Framework), or connect runways (that is Integration Hub). It oversees everything from above - strategy, safety rules, operations, and performance metrics. AI Control Tower does the same for enterprise AI.
Real-World Example
A global insurance company has deployed Now Assist for IT agents, a custom ML model for claims fraud detection, and a third-party GPT tool for policy document summarization. Their CIO uses AI Control Tower to see all 3 AI initiatives in one dashboard: tracking that the fraud model achieves 94% accuracy (performance), ensuring the GPT tool complies with data privacy regulations (governance), verifying each initiative maps to the "Digital Transformation" strategic objective (strategy), and monitoring that 1,200 agents are actively using Now Assist (management).
- AA Reference field
- BA Parent field
- CA Choice field
- DA Mandatory field
Show full explanation
Correct Answer
B. A Parent field
Source
ServiceNow Zurich - Table Extension and Classes
If the link fails, search Google for: ServiceNow Zurich table extension parent field inheritance
Expert Explanation
In ServiceNow, table inheritance (also called table extension) is implemented through the Parent field. When Table B extends Table A, Table B inherits all of Table A's fields. This creates a hierarchy where:
- The Parent field on the child table points to the parent table, establishing the extension relationship
- All fields from the parent table are automatically inherited by the child table and any tables that extend the child
- If the Parent field is deleted, the extension relationship is severed, causing the platform to cascade-delete all inherited fields from the child tables
This is why deleting a single Parent field can result in the automatic removal of many fields across several tables - every table in the inheritance chain below that point loses its inherited columns.
Why the Others Are Wrong
- A. Reference field - Creates a foreign-key-style relationship (stores a sys_id pointing to another table's record). Deleting it removes one column only. No cascading field deletions occur.
- C. Choice field - A field with a dropdown list of values. Deleting it removes one column. Choice lists are stored separately in sys_choice but the field deletion does not cascade to other tables.
- D. Mandatory field - "Mandatory" is an attribute on a field, not a field type. Removing any field - mandatory or not - only deletes that single column unless it is a Parent field.
Memory Tip
Think of a family tree: the Parent passes traits (fields) to all children (extended tables). If you erase the Parent from the tree, all the inherited traits disappear from every descendant. Reference is just a phone number pointing to someone else - deleting it does not affect their DNA.
Real-World Example
A developer at a logistics company created a custom "Shipment" table that extended the core Task table. The Shipment table inherited 40+ fields from Task (like State, Assignment Group, Short Description). When the developer accidentally deleted the Parent field on the Shipment table, all 40 inherited fields vanished from Shipment and from "Express Shipment" (which extended Shipment) - a total of 80+ field deletions from just removing one Parent field. The fix required restoring the Parent field relationship from an update set backup.
- ADevelopers can push updates to any server in the team development hierarchy without restriction.
- BPushing updates requires the use of the git_admin role.
- CUpdates can only be pushed to child instances never to parent instances.
- DDevelopers typically have restricted push privileges and pushes are usually limited to the parent instance within the hierarchy.
Show full explanation
Correct Answer
D. Developers typically have restricted push privileges and pushes are usually limited to the parent instance within the hierarchy.
Source
ServiceNow Zurich - Team Development
If the link fails, search Google for: ServiceNow Zurich Team Development push pull hierarchy
Expert Explanation
Team Development is ServiceNow's built-in multi-instance development framework that allows teams to work on changes in parallel across different instances and then merge those changes. The hierarchy typically follows this pattern:
- Development instances (bottom) - Where developers build and test
- Integration/Test instance (middle) - Where changes are merged and validated
- Production instance (top) - Where approved changes are deployed
Key rules about push privileges:
- Developers can push updates upward to their parent instance in the hierarchy
- Push access is restricted by role and configuration - not every developer can push to every instance
- The parent instance is the typical target for pushes from a development instance
- Administrators control who can push and to which instances through Team Development settings
Why the Others Are Wrong
- A. Push to any server without restriction - This would defeat the purpose of having a controlled hierarchy. Team Development enforces strict paths to prevent unauthorized changes from reaching higher environments.
- B. Requires git_admin role - There is no standard "git_admin" role in ServiceNow. Team Development uses its own role model (admin, teamdev_user) and is not a Git-based system despite having version control concepts.
- C. Only to child instances, never parent - This is backwards. The normal flow is pushing to the parent instance (upward), not to child instances. Developers push their completed work up the chain for integration and eventual production deployment.
Memory Tip
Think of a corporate approval chain: an employee (developer) submits their work up to their manager (parent instance) - not to any random department, not using a fake badge (git_admin), and definitely not only downward. Up to parent, with restrictions.
Real-World Example
At a retail company with 3 ServiceNow instances (Dev, Test, Prod), two developers - Sarah and Mike - each build features on the Dev instance. When Sarah finishes her catalog item customization, she pushes her update set to the Test (parent) instance. She cannot push directly to Prod because her push privileges only allow access to the immediate parent. The release manager on the Test instance reviews the changes and handles the final push to Prod after UAT is complete.
- Aadmin_count
- Bmax_admin_count
- Cnum_admin
- Dmin_admin_count
Show full explanation
Correct Answer
D. min_admin_count
Source
ServiceNow Zurich - Application Scope Properties
If the link fails, search Google for: ServiceNow Zurich min_admin_count application administrator property
Expert Explanation
The min_admin_count property defines the minimum number of users who must be assigned the Application Administrator role (x_[scope]_[app].admin) for a scoped application. This is a governance safeguard that prevents situations where a scoped application has zero administrators, which would make it impossible to manage the application's settings, access controls, and cross-scope permissions.
Key details about this property:
- It sets a floor (minimum threshold) for admin role assignments
- If the number of admins drops below this value, the platform can warn or prevent the removal of the last qualifying administrator
- This is especially important for scoped applications where the Application Administrator controls access to the app's tables, scripts, and configurations
- The default value ensures at least one person can always manage the application
Why the Others Are Wrong
- A. admin_count - Not a real ServiceNow property. The name is too generic and does not specify whether it tracks a minimum, maximum, or current count.
- B. max_admin_count - The "max_" prefix would indicate a maximum limit, which is the opposite of what the question asks. The question specifically asks about the minimum amount.
- C. num_admin - Not a real ServiceNow property. This might suggest a current count rather than a constraint, and it does not follow ServiceNow's property naming patterns.
Memory Tip
The property name tells you exactly what it does: min (minimum) + admin (administrator) + count (number). It is the "minimum admin count" - the fewest admins you are allowed to have. When in doubt, ServiceNow property names are usually self-describing.
Real-World Example
A ServiceNow admin at a university sets min_admin_count to 2 for their custom Student Services application. When one of the two application administrators, Professor Chen, transfers to another department and their admin role is about to be removed, the system flags that removing this assignment would drop the admin count below the minimum threshold of 2. The IT team must first assign another user as Application Administrator before Professor Chen's role can be revoked, ensuring the app always has adequate administrative coverage.
- AThe column is immediately pushed to the base instance via a synchronous background script.
- BThe schema change forces the table to become isolated within the sandbox; any records added subsequently are isolated from the base instance.
- CThe sandbox is immediately flagged for retirement due to a base-instance collision.
- DThe base instance locks the table preventing any other sandboxes from accessing it until the changes are merged.
Show full explanation
Correct Answer
B. The schema change forces the table to become isolated within the sandbox; any records added subsequently are isolated from the base instance.
Source
ServiceNow Zurich - Developer Sandbox
If the link fails, search Google for: ServiceNow Zurich Developer Sandbox data isolation schema change
Expert Explanation
Developer Sandboxes provide isolated development environments where developers can build and test without affecting the base instance. A key concept is the distinction between shared and isolated data tables:
- Shared tables - Data is shared with the base instance in real-time. The sandbox reads and writes to the same data as the base instance.
- Isolated tables - Data exists only within the sandbox. Changes do not affect the base instance.
When a developer modifies the schema of a shared table (by adding, removing, or altering columns), the platform automatically transitions that table from shared to isolated. This happens because:
- The schema of the sandbox table no longer matches the base instance table
- Shared data access requires identical schemas between sandbox and base
- After isolation, new records are only visible within the sandbox
- Existing shared data may be copied into the sandbox at the point of isolation
Why the Others Are Wrong
- A. Synchronous push to base instance - This would be dangerous. Sandboxes exist specifically to prevent unvetted changes from reaching the base instance. Schema changes stay sandboxed until explicitly committed through a proper merge process.
- C. Sandbox flagged for retirement - Schema changes are expected developer activities, not errors. The sandbox handles this gracefully by isolating the table. No retirement or collision flag is generated.
- D. Base instance locks the table - Sandboxes operate independently. One sandbox's schema change has no effect on other sandboxes or the base instance. There is no cross-sandbox locking mechanism triggered by schema modifications.
Memory Tip
Think of a shared Google Sheet (shared table). If you change the column headers (schema), Google cannot keep it synced with the original. It becomes your own copy (isolated). New rows you add exist only in your copy. Same principle: change the schema = break the share = table becomes isolated.
Real-World Example
A developer at an e-commerce company is working in her Developer Sandbox on the shared Order table. She adds a new "Shipping Priority" column to test a feature. Immediately, the Order table transitions from shared to isolated in her sandbox. She inserts 50 test orders with the new field populated. None of these 50 records appear in the base instance, and the base instance Order table still has its original schema. When she is satisfied with the feature, she commits her changes through the proper merge process to bring the schema change and relevant data into the base instance.
- ACheck the "Client callable" checkbox on the Script Include record.
- BSet the "Accessible from" field to "All application scopes".
- CExtend the AbstractAjaxProcessor class in the script.
- DUse the gs.include() method inside the Client Script.
Show full explanation
Correct Answer
A. Check the "Client callable" checkbox on the Script Include record.
C. Extend the AbstractAjaxProcessor class in the script.
Source
If the link fails, search Google for: ServiceNow Zurich GlideAjax Script Include Client callable AbstractAjaxProcessor
Expert Explanation
When a Client Script needs to call server-side logic, the standard pattern is to use GlideAjax with a properly configured Script Include. Two mandatory steps make this work:
- Client callable checkbox - This flag on the Script Include record exposes the script to client-side AJAX calls. It is a security gate that prevents unauthorized client access to server-side code.
- Extend AbstractAjaxProcessor - The Script Include class must extend AbstractAjaxProcessor, which provides the plumbing for receiving client parameters (via
getParameter()), processing the request, and returning results.
The typical GlideAjax pattern:
- Server side: Create a Script Include that extends AbstractAjaxProcessor, check "Client callable", and define functions that process parameters and return values
- Client side: Create a
new GlideAjax('ScriptIncludeName'), add parameters withaddParam(), and callgetXMLAnswer()with a callback function
Why the Others Are Wrong
- B. Set "Accessible from" to "All application scopes" - This field controls server-side cross-scope access, not client-side access. A Script Include can be client callable within its own scope without being accessible to all scopes.
- D. Use gs.include() in the Client Script -
gs.include()is a server-side method for including script libraries. It is not available in Client Scripts, which run in the browser. The client-side mechanism is GlideAjax, not gs.include().
Memory Tip
Remember the two C's of GlideAjax: Checkbox (Client callable) and Class (AbstractAjaxProcessor). Without the Checkbox, the phone line is disconnected. Without the Class, there is no one to answer the call.
Real-World Example
A developer at a telecom company needs a catalog item form to validate a customer's phone number against a server-side database in real-time. She creates a Script Include called "PhoneValidator" that extends AbstractAjaxProcessor and checks the "Client callable" box. The script has a function validateNumber() that queries the Customer table. On the catalog item form, an onChange Client Script uses new GlideAjax('PhoneValidator') with addParam('sysparm_name', 'validateNumber') to call the server, receiving an instant response of "valid" or "invalid" without a full page reload.
- ABy automatically translating all queries into SQL stored procedures.
- BBy enforcing standard programming logic where logical AND takes precedence over logical OR preventing improper data filtering.
- CBy requiring developers to execute raw SQL directly against the MariaDB database.
- DBy restricting all database calls to a maximum return of 100 records per transaction.
Show full explanation
Correct Answer
B. By enforcing standard programming logic where logical AND takes precedence over logical OR preventing improper data filtering.
Source
ServiceNow Zurich - GlideQuery API
If the link fails, search Google for: ServiceNow Zurich GlideQuery API AND OR precedence filtering
Expert Explanation
The GlideQuery API was introduced to address several shortcomings of the legacy GlideRecord API, with the most significant being the logical filtering flaw related to AND/OR operator precedence.
The GlideRecord problem:
- In GlideRecord,
addQuery()adds AND conditions andaddOrCondition()adds OR conditions - These methods do not follow standard Boolean logic where AND binds more tightly than OR
- Complex queries with mixed AND/OR conditions can produce unexpected results because the conditions are evaluated left-to-right without proper grouping
- Developers must use
addEncodedQuery()with manual parentheses to work around this issue
The GlideQuery solution:
- GlideQuery uses a fluent, chainable API with
.where(),.and(), and.or()methods - The API enforces standard Boolean precedence: AND operations take precedence over OR operations
- Nested conditions are handled through structured method chaining, eliminating ambiguity
- This prevents the "improper data filtering" bugs that plague complex GlideRecord queries
Why the Others Are Wrong
- A. Translates to SQL stored procedures - ServiceNow never generates stored procedures. Both GlideRecord and GlideQuery are abstraction layers over the platform's internal query engine. No direct SQL is involved.
- C. Requires raw SQL - Direct SQL access is prohibited in ServiceNow for security and data integrity. GlideQuery is specifically designed to be a higher-level abstraction, not a lower-level one.
- D. Maximum 100 records per transaction - No such limit exists. GlideQuery supports
.limit()as a best practice, but it does not enforce a 100-record cap. Developers control result set sizes.
Memory Tip
Think of a math equation: 2 + 3 x 4. In standard math, multiplication (AND) goes first: 2 + 12 = 14. But GlideRecord treats it left-to-right: 5 x 4 = 20. GlideQuery follows the math rules - AND before OR, just like multiplication before addition.
Real-World Example
A developer at a hospital needs to query incidents that are either Priority 1 AND assigned to the Network team, OR Priority 2 AND assigned to the Server team. With GlideRecord, mixing addQuery and addOrCondition produces wrong results - it returns all P1 incidents plus all Server team incidents regardless of priority. With GlideQuery, the developer writes new GlideQuery('incident').where('priority', 1).and('assignment_group', networkTeam).or(new GlideQuery('incident').where('priority', 2).and('assignment_group', serverTeam)) and gets exactly the correct 47 records instead of the erroneous 312 that GlideRecord returned.
- APush to update set
- BMerge branches
- CSearch code
- DPush to external source control
Show full explanation
Correct Answer
C. Search code
D. Push to external source control
Source
ServiceNow Zurich - ServiceNow Studio
If the link fails, search Google for: ServiceNow Zurich Studio IDE features source control search
Expert Explanation
ServiceNow Studio is the integrated development environment (IDE) for building scoped applications on the Now Platform. It provides a consolidated workspace with several key features:
- Search code - Allows developers to search across all application files including scripts, UI pages, and configuration records. This is accessed through the Studio interface and supports text-based searching across the entire application scope.
- Push to external source control - Studio integrates with Git-based repositories (GitHub, GitLab, Bitbucket, Azure DevOps) allowing developers to version-control their application code externally. This enables branching, collaboration, and code backup outside ServiceNow.
Other notable Studio features include:
- Application file navigation and creation
- Script editing with syntax highlighting and code completion
- Linking to source control repositories
- Application publishing to the ServiceNow Store
Why the Others Are Wrong
- A. Push to update set - Update sets are a separate mechanism managed through the System Update Sets module, not through Studio. Studio works with source control, not update sets. Developers switch between update sets using the update set picker, not a Studio feature.
- B. Merge branches - While Studio supports pushing to and pulling from external source control, branch merging is performed in the external Git system (GitHub, GitLab, etc.), not within Studio itself. Studio handles push/pull operations but not merge conflict resolution.
Memory Tip
Studio has two S's and a P: Search code, Source control link, and Push to external source control. It does NOT have U (Update sets) or M (Merge) - those belong to other tools. Think: "Studio Searches and Pushes."
Real-World Example
A team of 4 developers at an energy company uses Studio to build a custom Asset Inspection application. Developer Maria uses the Search code feature to find all references to the "inspection_status" field across 23 script files before refactoring it. When she finishes her changes, she uses Push to external source control to push the updated application to their company GitHub repository, where it triggers a CI pipeline that runs automated tests. Her colleague Raj then pulls the latest version from the same repo into his development instance to continue building on her work.
- AA method to track users involved in developing the application.
- BA namespace (prefix and scope name) to prevent cross-application name collisions.
- CA means to control which roles can view the application and its related modules.
- DA means to control how scripts from other scopes can alter tables in a scoped application.
Show full explanation
Correct Answer
B. A namespace (prefix and scope name) to prevent cross-application name collisions.
D. A means to control how scripts from other scopes can alter tables in a scoped application.
Source
ServiceNow Zurich - Application Scope
If the link fails, search Google for: ServiceNow Zurich Application Scope namespace cross-scope access
Expert Explanation
Application Scoping is a foundational concept in ServiceNow that provides two critical capabilities for custom application development:
1. Namespace isolation:
- Every scoped application gets a unique namespace:
x_[vendor_prefix]_[app_name] - All artifacts (tables, scripts, UI components) are prefixed with this namespace
- This prevents naming collisions - two apps can both have a "Configuration" table without conflict (e.g.,
x_acme_hr.configurationvsx_beta_it.configuration)
2. Cross-scope access control:
- Application developers define access policies that control whether external scripts can interact with their tables
- Options include: allow/deny read, write, create, delete operations from other scopes
- The Application Cross-Scope Access table tracks and governs these interactions
- This prevents one application from inadvertently or maliciously modifying another application's data
Why the Others Are Wrong
- A. Track users involved in development - This is a project management concern, not an application scoping feature. Development tracking is handled by update set history, Team Development, and external tools like Jira.
- C. Control which roles can view the application - Role-based access to modules and menus is managed through Application Menus, Module records, and ACLs. While scoped apps have their own roles (like x_myco_myapp.user), the scoping mechanism itself does not control module visibility.
Memory Tip
Application Scoping does two things - think Name and Protect. Namespace prevents collisions (like postal codes prevent address confusion). Protection controls who can touch your data (like a fence around your yard). It does NOT track developers (that is HR) or control menu visibility (that is security).
Real-World Example
Two departments at an airline independently build custom apps. The HR team builds x_airline_hr with a "Requests" table for employee leave requests. The Maintenance team builds x_airline_maint with a "Requests" table for aircraft part orders. Thanks to namespace isolation, both "Requests" tables coexist without conflict. The HR team also sets cross-scope access on their table to "deny write" from other scopes, preventing the Maintenance app's scripts from accidentally modifying employee leave records when both apps are installed on the same production instance.
- AEmail Notifications
- BFlow Designer Email Triggers
- CInbound Email Actions
- DNotification Mail Scripts
Show full explanation
Correct Answer
C. Inbound Email Actions
Source
ServiceNow Zurich - Inbound Email Actions
If the link fails, search Google for: ServiceNow Zurich Inbound Email Actions parse create records
Expert Explanation
Inbound Email Actions (also known as Inbound Actions) are the dedicated ServiceNow feature for processing incoming emails. They provide a complete framework for:
- Parsing - Extracting data from email subject lines, body content, headers, and attachments
- Condition evaluation - Matching incoming emails against defined criteria (sender address, subject patterns, body keywords)
- Record creation - Automatically creating new records (incidents, requests, tasks) from email content
- Record updates - Updating existing records when reply emails contain a watermark or reference number
Key components of an Inbound Email Action:
- Target table - The table where records will be created or updated
- Conditions - Rules that determine when this action fires (e.g., subject contains "urgent")
- Script - Server-side code that processes the email object and maps content to record fields
- Email variables - Pre-built variables like
email.subject,email.body_text,email.fromavailable in the script
Why the Others Are Wrong
- A. Email Notifications - These are outbound only. They send emails when events occur (like incident creation). They cannot receive or parse incoming emails.
- B. Flow Designer Email Triggers - While Flow Designer can react to email events, it is a general automation tool. Inbound Email Actions are the expressly designed feature for email parsing and record creation, making them the more precise answer.
- D. Notification Mail Scripts - These customize outbound notification content using scripts. They format what goes into outgoing emails, not what comes from incoming ones.
Memory Tip
The name says it all: Inbound (coming in) Email (the medium) Actions (what happens). Everything else is about outbound: Notifications send out, Mail Scripts format outgoing content. Only Inbound Email Actions handle incoming mail and take action on it.
Real-World Example
An IT help desk at a manufacturing plant receives 200+ support emails daily to helpdesk@company.com. Their Inbound Email Action is configured with three conditions: if the subject contains "password reset" it creates a Request on the Password Reset catalog item; if the email comes from the monitoring system (alerts@monitoring.internal) it creates a Priority 2 Incident with the alert details parsed from the body; and if the email is a reply to an existing incident (detected by the watermark [INC0012345]), it adds the email body as a work note to the matching incident record.
- Acurrent
- Bprevious
- CGlideSystem (gs)
- Dg_scratchpad
Show full explanation
Correct Answer
B. previous
D. g_scratchpad
Source
ServiceNow Zurich - Business Rules
If the link fails, search Google for: ServiceNow Zurich Business Rule variables previous g_scratchpad availability
Expert Explanation
Business Rules in ServiceNow receive several global variables in their execution environment. However, not all variables are available in every Business Rule type. Here is the breakdown:
Universally available (all types):
- current - The GlideRecord of the record being operated on
- gs (GlideSystem) - Server-side utility API for logging, user info, events, etc.
NOT universally available:
- previous - Contains the record's field values before the current update. Only available in before and after Business Rules. Not available in async rules (the transaction is complete and previous state is released) or display rules (no update is occurring).
- g_scratchpad - A special object for passing server-side data to client-side scripts. Only available in display Business Rules. Not available in before, after, or async rules because they do not participate in the form rendering pipeline.
Why the Others Are Wrong
- A. current - This IS universally available. Every Business Rule operates on a record, and
currentalways points to that record regardless of the rule type. - C. GlideSystem (gs) - This IS universally available. The gs object is a core server-side API accessible in all server-side scripts, including all Business Rule types.
Memory Tip
Think of a time machine: previous only works when you are in the present moment of an update (before/after) - you cannot look back from an async future. g_scratchpad is a sticky note passed from server to client - it only works at the display counter where the form is being assembled. Neither of these works everywhere.
Real-World Example
A developer at a bank writes 4 Business Rules on the Account table. In her "before" rule, she compares current.balance with previous.balance to detect large withdrawals - this works because previous is available. In her "display" rule, she sets g_scratchpad.accountTier = 'Premium' so the form's Client Script can show a gold banner - this works because g_scratchpad is available in display rules. When she tries to use previous in her "async" rule to send a notification comparing old and new values, it fails silently because previous is null in async context. She refactors the async rule to store the old value in an event parameter instead.
- AAvailable licenses
- BBusiness problem
- CProcess steps
- DUsers/stakeholders
- EDatabase capacity
- FProject schedule G. Data input/output
Show full explanation
Correct Answer
B. Business problem
C. Process steps
D. Users/stakeholders
Source
ServiceNow Zurich - Planning the Application
If the link fails, search Google for: ServiceNow Zurich application development plan business requirements documentation
Expert Explanation
ServiceNow's application development methodology emphasizes thorough planning before building. The application development plan must document key business requirements and processes to ensure the application solves the right problems for the right people. The three essential elements are:
- Business problem - Clearly defines what issue or need the application addresses. This is the foundation that justifies the application's existence and guides all design decisions.
- Process steps - Documents the workflow, sequence of activities, decision points, and handoffs that the application must support. This translates business operations into application logic.
- Users/stakeholders - Identifies all personas who interact with or are affected by the application. This drives role design, UI decisions, notification requirements, and access controls.
Together, these three elements answer the critical questions: Why are we building this (business problem)- How does the process work (process steps)- Who is involved (users/stakeholders)-
Why the Others Are Wrong
- A. Available licenses - This is a procurement and platform administration concern, not a business requirement. It affects technical feasibility but does not define what the application should accomplish.
- E. Database capacity - ServiceNow is a managed cloud platform. Database capacity is handled at the infrastructure level and is not a business requirement that shapes application design.
- F. Project schedule / G. Data input/output - Project schedule is a project management artifact, not a business requirement. While data input/output may be relevant to technical specifications, it is not listed among the core business requirements and processes that ServiceNow recommends documenting in the development plan.
Memory Tip
Remember P-P-U: Problem (why), Process (how), Users (who). These are the three pillars of any application plan. Everything else (licenses, capacity, schedules) is logistics, not requirements. Ask yourself: "Does this define what the app should do-" If not, it is not a core development plan element.
Real-World Example
A ServiceNow developer at a university is tasked with building a Student Equipment Loan application. Her development plan documents: (1) Business problem - students currently fill out paper forms to borrow lab equipment, causing 3-day delays and 15% loss rate due to no tracking. (2) Process steps - student submits request, lab manager reviews availability, equipment is checked out with barcode scan, automated return reminders at day 5 and day 7, overdue escalation to department chair. (3) Users/stakeholders - 2,000 students (requesters), 12 lab managers (approvers/fulfillment), 3 department chairs (escalation), IT team (admins). She explicitly excludes database capacity and license counts from the plan because those are handled by the university's ServiceNow platform team.
- AThe Flow Debugger cannot execute logic against a custom scoped application.
- BThe Flow Debugger does not provide native database rollback functionality to revert test records.
- CThe Flow Debugger is incapable of inspecting data pills nested within a subflow.
- DThe Flow Debugger requires the user to possess the security_admin role.
Show full explanation
Correct Answer
B. The Flow Debugger does not provide native database rollback functionality to revert test records.
Source
ServiceNow Zurich - Flow Debugger
If the link fails, search Google for: ServiceNow Zurich Flow Debugger limitations rollback ATF comparison
Expert Explanation
The Flow Debugger and the Automated Test Framework (ATF) are both testing tools in ServiceNow, but they have a critical difference regarding data management:
Flow Debugger:
- Allows step-by-step execution and inspection of Flow Designer flows
- Shows data pill values at each step for debugging logic
- Does NOT roll back database changes - any records created, updated, or deleted during debugging persist in the instance
- Developers must manually clean up test data after debugging sessions
Automated Test Framework (ATF):
- Provides structured test cases with assertions for automated testing
- Includes native database rollback - automatically reverts all data changes made during test execution
- Returns the instance to its pre-test state after each test run
- This makes ATF safe for repeated testing without data pollution
This rollback limitation is the most significant practical difference between the two tools. It means Flow Debugger is best used in development or sandbox environments where persistent test data is acceptable, while ATF is suitable for all environments including production-like instances.
Why the Others Are Wrong
- A. Cannot execute against custom scoped applications - The Flow Debugger works with flows in any application scope, including custom scoped applications. There is no scope restriction on debugging.
- C. Cannot inspect data pills in subflows - The Flow Debugger provides full inspection capabilities including nested subflow data pills. Developers can expand subflow steps and examine every data pill value at every execution point.
- D. Requires security_admin role - The Flow Debugger requires the flow_designer role or admin role, not security_admin. The security_admin role is for ACL and security policy management, not flow development.
Memory Tip
Think of the Flow Debugger as a live cooking demonstration - you make real food (real data) and it stays on the counter (in the database). ATF is like a cooking simulation game - everything resets (rolls back) when you finish. The debugger is real, ATF is reversible.
Real-World Example
A developer at a shipping company debugs a flow that creates a Shipment record and sends a notification to the warehouse team. After 15 debugging runs, there are 15 orphaned Shipment records in the database and the warehouse team received 15 test notifications. She then switches to ATF for regression testing - running the same flow 50 times with assertions, and every Shipment record and notification is automatically rolled back after each test. The database stays clean and the warehouse team receives zero test emails. This is why her team uses Flow Debugger for initial development and ATF for ongoing testing.
Free exam updates. No spam. Unsubscribe anytime.
You scored 0/15 on the 15-question preview.
The full course keeps the same answer breakdown style across all 325 questions.
Your first exam attempt is free. Your second costs $350.
Many students also study:
Compare all 18 practice tests, or use the cert quiz to plan what to study next.
Read the full CAD study guide for domain weights, a 6-week plan, and scripting tips.
Looking for a different certification?
Browse all 18 practice tests →