ServiceNow CAD Certified Application Developer - ServiceNow Exam Practice Test

In ServiceNow, GlideForm is the client-side API used to interact with and manipulate a record form, including reading and writing field values, controlling visibility/mandatory/read-only behavior, and displaying messages to the user. The platform exposes GlideForm methods through a single global client-side object named g_form. ServiceNow documentation explicitly states that there is no constructor for the GlideForm class and that developers access GlideForm methods using the g_form global object available in client-side contexts such as Client Scripts and UI Policies. This makes g_form the correct and standard way to call GlideForm functions (for example, g_form.getValue(), g_form.setValue(), g_form.setDisplay(), etc.). The other options listed are not the documented GlideForm global object for standard client scripting in ServiceNow.

In ServiceNow, when importing data from external sources, the platform utilizes Import Sets to stage the data before transforming it into target tables. The mechanism that defines how data from the Import Set fields map to the fields in an existing ServiceNow table is called a Transform Map.

Transform Map: A Transform Map is a set of field mappings that determine the relationships between fields in an Import Set and fields in an existing ServiceNow table. It allows administrators to define how data should be transformed and inserted into the target table.

servicenow.com

Business Service Management Map: This is not related to data import processes. It pertains to visual representations of business services and their dependencies.

Schema Map Relationship Builder: The Schema Map provides a graphical representation of tables and their relationships within the database schema but does not handle data import mappings.

Data Sources: Data Sources define the origin of the data being imported (e.g., files, JDBC connections) but do not determine the field mappings between Import Sets and target tables.

The purpose of application scoping is NOT to provide a way of tracking the user who developed an application. Application scoping does not store or display information about the user who created or modified an application or its artifacts. The purpose of application scoping is to provide a relationship between application artifacts, provide a namespace to prevent cross-application name collisions, and provide controls for how scripts from another scope can alter tables in a scoped application. References: [Product Documentation | ServiceNow], [Advantages of Scoped Applications in ServiceNow]

ServiceNow provides the Schema Map as the platform feature specifically designed to display a graphical representation of how tables relate to one another. In application development, tables commonly extend other tables and also reference other tables through reference fields. The Schema Map visualizes these relationships so developers can quickly understand the structure of the data model, including parent-child extensions and reference connections. This is especially useful when you are designing an application’s data model, troubleshooting why a field appears on multiple tables, or assessing the impact of adding a new relationship. The Schema Map is not a general “graphical user interface” concept; it is a dedicated view focused on the database schema. Likewise, a “dependency view” may exist for other platform features (such as dependency relationships for services or configuration items), but it is not the standard tool used to explore table-to-table schema relationships during application development. Because the question asks for a graphical view of relationships among tables, the correct documented feature is Schema Map.

A transform map determines the relationships between fields displaying in an Import Set table and fields in an existing ServiceNow table, such as the Incidents or Users table.

In ServiceNow, Access Controls (ACLs) determine the permissions required for users to access or modify data. For a user to pass an Access Control, the following conditions must be met:

Conditions configured in the Access Control must evaluate to true: Access Controls can have specific conditions set in the " Condition " field. These conditions are evaluated against the current record, and must return true for the Access Control to grant access.

The user has one of the roles specified in the Required roles related list: Access Controls can specify certain roles that a user must possess to gain access. If the user holds at least one of these roles, this criterion is satisfied.

Scripts configured in the Access Control must evaluate to true: Access Controls can include scripts that perform more granular checks. The script must execute without errors and return true for the user to pass the Access Control.

Option A is incorrect because Business Rules do not grant access; they are server-side scripts that execute based on record operations but do not control security permissions.

Option D is misleading. Each Access Control is evaluated independently. While multiple Access Controls can apply to a single operation, passing one does not inherently grant access unless it is the most specific match.

For more detailed information, refer to the official ServiceNow documentation on Access Controls:

servicenow.com

https://docs.servicenow.com/bundle/tokyo-application-development/page/script/server-scripting/concept/c_ServerScripting.html

In ServiceNow, UI Actions are elements that make the user interface more interactive and tailored to user activities. They can appear as buttons, links, or context menu items on forms and lists. The valid types of UI Actions include:

C. Form choice: These are UI Actions that appear as choices in form context menus, allowing users to perform specific actions related to the form.

D. Form button: These are buttons that appear on forms, enabling users to execute defined actions directly from the form view.

E. List banner button: These are buttons that appear in the list view ' s banner, providing actions that can be performed on the list or selected records.

The other options are not standard UI Action types:

A. Workflow action: While workflows can include actions, " Workflow action " is not a defined UI Action type in ServiceNow.

B. Record navigation button: This is not a standard term used for UI Action types in ServiceNow.

In ServiceNow, the gs object provides a range of methods for logging messages on the server side. However, the availability of these methods can vary depending on whether the application is global or scoped.

gs.info(): This method is available in scoped applications and is used to log informational messages to the system log. It provides a way to record general information during script execution.

Options A (gs.log()), B (gs.print()), and D (gs.debugLog()) are not available in scoped applications. These methods are either restricted to global applications or do not exist in the ServiceNow API.

For more detailed information, refer to the official ServiceNow documentation on server-side scripting:

The Guided Application Creator (GAC) is a tool that helps you create applications on the ServiceNow platform by guiding you through the steps of defining the data model, user interface, and logic. When using the GAC, you can designate data tables in three ways:

Upload an existing PDF: You can upload a PDF file that contains the table schema and sample data. The GAC will parse the PDF and create the table and fields based on the file content.

Create a new table on the platform: You can create a new table on the platform by specifying the table name, label, and description. You can also add fields, indexes, and relationships to the table using the GAC.

Upload an existing spreadsheet: You can upload a spreadsheet file that contains the table schema and sample data. The GAC will parse the spreadsheet and create the table and fields based on the file content.

The other options are not valid ways to designate data tables when using the GAC. You cannot upload an existing word processing document or use a freeform database. You can use an existing table on the platform, but you cannot designate it as a data table. You can only use it as a reference table for lookup fields.

https://developer.servicenow.com/dev.do#!/learn/learning-plans/rome/new_to_servicenow/app_store_learnv2_scripting_rome_debugging_client_scripts

The following are debugging strategies for client-side scripts, which run in the web browser and manipulate the user interface:

g_form.addInfoMessage(). This is a client-side API that displays an information message at the top of the form.

Field Watcher. This is a debugging tool that displays the current and previous values of one or more fields on a form.

jslog(). This is a client-side API that writes a message to the browser console.

The following is not a debugging strategy for client-side scripts, but for server-side scripts, which run on the ServiceNow platform and manipulate the database:

gs.log(). This is a server-side API that writes a message to the system log. References: Client-Side Scripting APIs, Debugging Client Scripts

https://docs.servicenow.com/bundle/tokyo-application-development/page/app-store/dev_portal/API_reference/glideSystemScoped/concept/c_GlideSystemScopedAPI.html

In ServiceNow, the " Allow access to this table via web services " option within the Application Access settings determines whether the table can be accessed through web service protocols, such as REST and SOAP. When this option is selected, it permits the table to be accessible via web services; however, it does not override existing permissions. The user or system making the web service request must still have the appropriate permissions (such as roles and access controls) to perform operations on the table ' s records.

Option A: Incorrect. If the " Allow access to this table via web services " option is not selected, the table is not accessible via web services, regardless of user permissions.

Option B: Correct. Enabling this option allows the table to be accessed via web services, but the user must have the correct permissions to access the table ' s records.

Option C: Incorrect. This option applies to all web service protocols, including both SOAP and REST.

Option D: Incorrect. This option controls overall web service access to the table; specific operations (create, read, update, delete) are governed by user permissions and access controls.

Inbound Action scripts are server-side scripts that run when an email is received by the system. They can use the current object to access the record that is created or updated by the email, and the email object to access the properties and methods of the email message. The previous and event objects are not available in Inbound Action scripts. The producer object is only available in Record Producer scripts, which are used to create records from a service catalog item.

https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/c_ScriptProtectionPolicy.html

The following is true for a Script Include with a Protection Policy value of Protected:

The Protection Policy is applied only if the application is downloaded from the ServiceNow App Store. This is true because the Protection Policy is a feature that allows developers to protect their Script Includes from being viewed or modified by other users when they distribute their applications through the ServiceNow App Store. The Protection Policy is only enforced when the application is installed from the App Store, not when it is developed or tested on the instance.

The following are not true for a Script Include with a Protection Policy value of Protected:

Any user with the protected_edit role can see and edit the Script Include. This is false because the protected_edit role is not related to the Protection Policy, but to the Access Control (ACL) rules. The protected_edit role allows users to edit protected fields on a table, such as the script field on the sys_script table, which stores the Business Rules. The Protection Policy does not use roles to control access to the Script Includes, but a cryptographic key that is generated when the application is published to the App Store.

The Protection policy option can only be enabled by a user with the admin role. This is false because the Protection policy option can be enabled by any user who has the application_admin role for the scoped application that contains the Script Include. The application_admin role grants full access to the application development and administration within the scope of the application.

The Protection Policy is applied only if the glide.app.apply_protection system property value is true. This is false because the glide.app.apply_protection system property is not related to the Protection Policy, but to the Application Restricted Caller Access (ARCA) feature. The ARCA feature allows developers to restrict the access to the Script Includes from other applications based on the caller’s scope. The glide.app.apply_protection system property determines whether the ARCA feature is enabled or disabled on the instance. References: Script Includes, Protect Script Includes, Application Restricted Caller Access

The ServiceNow App Repository is a central repository for all scoped applications that are published by all ServiceNow customers. It enables ServiceNow customers to upload and distribute applications between their instances. It also provides entitlements and version control for the applications.

ServiceNow application repository

Application Development Platform – ServiceNow

App Repo - ServiceNow Developer Blog

there are only two types of UX options: Mobile and Classic. Classic is defined as " manage records via lists and form "

 It is best practice to define the business requirements and the process(es) an application will manage as part of the application development plan. The following are some of the considerations to document as part of the business process:

Business problem. This is the description of the problem or opportunity that the application is intended to address or exploit. It should include the background, context, scope, and objectives of the problem or opportunity.

Data input/output. This is the specification of the data that the application will need to collect, store, manipulate, and display. It should include the data sources, formats, validations, transformations, and integrations of the data.

Users/stakeholders. This is the identification of the users and stakeholders who will be involved in or affected by the application. It should include the roles, responsibilities, expectations, and needs of the users and stakeholders.

Process steps. This is the definition of the steps and activities that the application will perform or support. It should include the inputs, outputs, triggers, conditions, and outcomes of each step or activity.

The following are not some of the considerations to document as part of the business process:

Project schedule. This is the estimation of the time and resources required to complete the application development project. It should include the milestones, deliverables, dependencies, and risks of the project. This is not part of the business process, but part of the project management plan.

Database capacity. This is the measurement of the amount of data that the application will generate and store in the database. It should include the data volume, growth rate, retention policy, and backup strategy of the data. This is not part of the business process, but part of the technical design and architecture of the application.

Available licenses. This is the number and type of licenses that the application will consume or require from the ServiceNow platform. It should include the license model, cost, and allocation of the licenses. This is not part of the business process, but part of the financial and legal aspects of the application. References: Application Development Process, Business Process Analysis

Flow Designer variables can store record data and complex data using the following data types:

Integer: A whole number that can be used in mathematical operations.

Array: A collection of items that can be accessed by their index or iterated over using a For each action.

String: Any kind of text, such as email addresses or the text contents of a file.

Define and Use Data Types in a Flow (Flow Designer)

Variable data types - Power Automate | Microsoft Learn

Product Documentation | ServiceNow

https://docs.servicenow.com/bundle/tokyo-platform-administration/page/administer/platform-events/reference/r_ScriptActions.html

The ServiceNow Store is a marketplace for free and paid certified ServiceNow applications and integrations. The ServiceNow Store provides customers with access to Now Certified enterprise workflow apps from partners that complement and extend ServiceNow products and solutions. Customers can browse, try, buy, and deploy apps and integrations that suit their needs and enhance their ServiceNow experience. The ServiceNow Store is not the source for ServiceNow Community created developer content, as that is available on the Developer Portal or the Share site. The ServiceNow Store is not a downloadable content ServiceNow script archive, as that is available on the Script Library or the Script Repository. The ServiceNow Store is not an alternate name for the ServiceNow Developer Share site, as that is a separate site where developers can share applications, code snippets, UI pages, etc. Reference: ServiceNow Store

A benefit of creating an Application Properties page for each application you develop is that Application Properties allow a developer or admin to make changes to an application’s behavior without modifying application artifacts. Application Properties are system properties that store configuration information for a specific application. They can be used to control various aspects of the application, such as feature flags, default values, thresholds, or URLs. By creating an Application Properties page, you can group and display all the properties related to your application in one place and make them easy to access and update. This way, you can avoid hard-coding static data in your application code and make your application more flexible and maintainable. Reference: Working with System Properties, Organizing your ServiceNow System Properties

Understanding Scoped Applications:Scoped applications in ServiceNow are designed to isolate and protect application-specific code and data. Server-side scripts within scoped applications can use the gs (GlideSystem) object for logging and debugging purposes. However, not all gs methods are appropriate or valid for scoped applications.

Valid Logging Methods in Scoped Applications:

gs.info():This method logs informational messages to the system log. It is commonly used for general-purpose logging when developers need to track execution flow or display debug data. Example:

gs.info( ' This is an informational log message. ' );

gs.error():This method logs error messages to the system log. It is used to indicate problems or issues encountered during script execution. Example:

gs.error( ' An error occurred during script execution. ' );

Incorrect Options Explained:

gs.debug() (Option B): This method is not valid in scoped applications. It is a legacy logging method available in the global scope but restricted in scoped applications.

gs.iog() (Option C): This is a typographical error and not a valid gs method in ServiceNow.

gs.logError() (Option E): This is not a recognized ServiceNow API method. To log errors, gs.error() is used instead.

Best Practices for Logging:

Logging should be meaningful and avoid unnecessary entries to keep logs clean and manageable.

Avoid excessive use of logging in production environments, as it can clutter the system logs and potentially degrade performance.

ServiceNow Developer Documentation on GlideSystem (gs)​.

SN Pro Tips on debugging and logging practices in scoped applications​.

A Module Link type defines how the module opens in the content pane when the user clicks on it in the navigation pane1. The URL (from Arguments) link type allows you to specify a URL that opens the Application Properties page for the selected application2. The URL can include arguments that are evaluated at runtime, such as the application name or scope3.

References = 1: Module link types - ServiceNow Docs 2: Application properties - ServiceNow Docs 3: URL (from Arguments) - ServiceNow Docs

Application Access is a feature that allows you to control the access level of other application scopes to your application’s data tables. By setting the Accessible from field value to This application scope only, you can restrict the access to your data tables to only your application scope. This means that other application scopes cannot create, read, write, or delete records on your data tables, unless they have explicit permissions through Access Controls or other means.

A Record Producer in ServiceNow is a specific type of catalog item that enables users to create records in a particular table through a simplified interface. They are often used to allow users to create task-based records, such as incidents or change requests, from the Service Catalog.

servicenow.com

Key characteristics of Record Producers include:

Graphics can be included on the user interface: Developers can enhance the user experience by adding images or icons to the Record Producer form, making it more intuitive and visually appealing.

Each field prompts the user with a question rather than a field label: Instead of standard field labels, Record Producers can present fields as questions to guide users in providing the necessary information. This approach makes the form more user-friendly and context-specific.

You can script behaviors of fields in the user interface: Developers have the flexibility to add client-side scripts to control the behavior of fields on the Record Producer form. This capability allows for dynamic interactions, such as showing or hiding fields based on user input or pre-populating fields with specific data.

Option A is incorrect because records created by a Record Producer are inserted into the table specified during its configuration, not necessarily the Requested Item [sc_req_item] table. Option C is incorrect because scripting is not mandatory for Record Producers; they can function without additional scripting, although scripting can be used to enhance functionality when needed.

The Application Repository is a central location for storing, managing, and distributing custom applications developed on the Now Platform.

From Developer Site > App Repo:

“The ServiceNow Application Repository stores custom applications and enables developers to distribute applications across multiple instances in their organization.”

ServiceNow Studio code search uses the default code search group to determine which application file types are searchable. To expand the supported file types, an administrator can create a new code search group that includes additional file types. This is cleaner than modifying a default table or changing unrelated metadata synchronization settings. The important CAD concept is that code search is metadata-driven and applies to searchable application file types, generally those extending sys_metadata. Creating a new code search group keeps the configuration controlled and avoids changing baseline behavior unnecessarily. Therefore, option A is the best answer for expanding supported Studio code search file types.

================

In ServiceNow, when a new field is added to an existing table, it is not automatically included in any existing List views. List views are predefined configurations that determine which fields are displayed when viewing records in a list format. To display the new field in a List view, you must manually modify the List layout to include the field.

Steps to Add a New Field to a List View:

Navigate to the List Layout Configuration:

Go to the table ' s list view.

Right-click on the header row (where the column titles are displayed).

Select " Configure " and then " List Layout. "

Add the New Field:

In the List Layout configuration, you ' ll see two columns: " Available " and " Selected. "

Locate your new field in the " Available " column.

Use the arrow buttons to move the new field to the " Selected " column, placing it in the desired order.

Save the Configuration:

Click " Save " or " OK " to apply the changes.

The new field will now appear in the List view as configured.

In ServiceNow, Business Rules are server-side scripts that execute whenever a record is inserted, updated, deleted, or queried. However, certain actions can be configured without writing any script, using the Business Rule ' s user interface options.

The primary actions that can be configured without scripting are:

Set field values: This allows administrators to specify new values for fields when the Business Rule conditions are met. This is configured in the " Actions " tab of the Business Rule form, where specific fields and their desired values can be set without any scripting.

Add message: Administrators can configure a message to be displayed to the user when the Business Rule executes. This is done by selecting the " Add message " checkbox and providing the desired message text.

Options C (Set field values and write to the system log) and D (Set field values and generate an event) would require scripting. Writing to the system log involves using server-side APIs like gs.log(), and generating an event requires calling event generation methods—both necessitate scripting.

For more detailed information, refer to the official ServiceNow documentation on Business Rules:

servicenow.com

The Automated Test Framework (ATF) is a tool that allows you to create and run automated tests on the ServiceNow platform. The ATF uses test steps to define the actions and validations for each test. The test step that allows you to create a user with specified roles and groups for the test is the Create a user test step. This test step creates a temporary user record that is deleted at the end of the test. You can specify the user name, password, roles, and groups for the user. You can also use the Impersonate a user test step to switch to the created user and perform actions as that user.

The other options are not valid test steps for creating a user. The Create a role and Create a group test steps do not exist in the ATF. To create a role or a group, you need to use the Create a record test step and specify the sys_user_role or sys_user_group table. The Impersonation test step does not create a user, but switches to an existing user.

https://docs.servicenow.com/bundle/tokyo-application-development/page/build/applications/task/t_IncludeApplicationData.html

Application scope is a foundational concept in ServiceNow application development. ServiceNow documentation describes application scoping as a protection mechanism that identifies and restricts access to an application’s files and data. In practice, scope defines an isolation boundary around an application’s artifacts, such as tables, scripts, UI components, and other resources. This boundary helps prevent unintended interference between applications and reduces the risk of naming collisions or cross-application impacts. The scope model also works together with Application Access settings, which allow administrators to specify what parts of an application are accessible to other applications. By default, scoped applications are designed to keep resources private unless explicitly shared through access settings or cross-scope privileges. Because of this, the primary purpose of scope is not backups or UI design control, and it is explicitly not meant to enable unrestricted updates across applications. Instead, scope exists to define and enforce boundaries so that an application’s resources remain isolated and protected unless intentionally exposed.

In ServiceNow, when importing data from external sources, the data is first loaded into an Import Set table, which acts as a staging area. To move this data into an existing ServiceNow table (known as the target table), a Transform Map is used. A Transform Map is a set of field mappings that define the relationships between fields in the Import Set table and fields in the target table. This mapping ensures that data is accurately transformed and transferred to the correct fields in the target table during the import process. Therefore, the correct answer is C. Transform Map.

The other options are not related to this specific function:

A. Business Service Management Map: This is not a standard term used in the context of data import and transformation in ServiceNow.

B. Data Sources: These define the origin of the data being imported but do not handle the field mapping between Import Set tables and target tables.

D. Schema Map Relationship Builder: This tool visualizes the relationships between tables in the database schema but is not used for mapping fields during data transformation.

For more detailed information, refer to the official ServiceNow documentation on Transform Maps.

In ServiceNow, UI Actions are elements such as buttons, links, and context menu items that allow users to perform actions on records or lists. The three valid UI Action types are:

1. List Banner Button (Option A)

Description: A button that appears in the list view header, allowing users to trigger an action affecting multiple records at once.

Example: A " Bulk Approve " button that processes selected records.

2. Form Button (Option B)

Description: A button that appears on a form, allowing users to trigger actions related to the current record.

Example: A " Submit for Approval " button on an incident form.

3. Record Navigation Button (Option D)

Description: A button that helps users navigate between related records.

Example: A " Go to Parent Record " button that redirects users to a linked record.

Incorrect Options:

Form Choice (Option C):

Not a UI Action type. Choices are typically used in choice fields (dropdowns) rather than UI actions.

List Choice (Option E):

Not a valid UI Action type. Similar to " Form Choice, " it pertains to field options rather than UI elements.

Workflow Action (Option F):

Workflows are process automation tools, not UI Actions. They are not directly related to buttons or links that users interact with.

https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/c_DefaultDesignAccessPermissions.html

The baseline behavior of a table in a privately-scoped application is that all application scopes can read from the table. A privately-scoped application is an application that restricts write access to its tables and resources to scripts within the same scope. However, read access is allowed by default for all scopes, unless the administrator explicitly denies it using an Access Control rule. This allows for data sharing between different applications while maintaining data integrity and security. References: [Product Documentation | ServiceNow], [Advantages of Scoped Applications in ServiceNow]

" A table that extends another table is called a child class, and the table it extends is the parent class " - this is about halfway down in this link below: https://docs.servicenow.com/en-US/bundle/tokyo-platform-administration/page/administer/table-administration/concept/table-extension-and-classes.html

In ServiceNow, a Record Producer allows users to create records in a specific table through the Service Catalog. After a user submits a Record Producer, developers may want to redirect the user to a specific page. This can be achieved by setting the producer.redirect property within the Script field of the Record Producer.

For example:

javascript

CopyEdit

producer.redirect = ' incident.do?sys_id= ' + current.sys_id;

This script redirects the user to the newly created incident record after submission.

Option A is incorrect because configuring the module that opens the Record Producer does not control the post-submission behavior.

Option C is unnecessary for simple redirection purposes; creating an application property to store the URL adds unnecessary complexity.

Option D is incorrect because using window.redirect in a Business Rule is not appropriate; Business Rules run on the server side and do not have access to the client-side

In ServiceNow, Application Files are configuration records that define the various components and logic that constitute an application. These include artifacts such as:

Business Rules

Client Scripts

UI Actions

Script Includes

Tables and Fields

Workflows

These artifacts collectively define the functionality and behavior of the application. When an application is developed, ServiceNow automatically creates and manages these Application Files to represent the application ' s components.

Option C is correct because Application Files are the fundamental building blocks that comprise a ServiceNow application, representing its various components and configurations.

Options A, B, and D are incorrect:

A: XML exports of an Update Set represent changes made to an instance but are not synonymous with Application Files.

B: CSV files are typically used for data import/export and do not represent the configuration components of an application.

D: An XML export of table records pertains to data within a table, not the configuration artifacts that define application behavior.

" Application developers must select an application as their current scope context. " https://docs.servicenow.com/bundle/tokyo-application-development/page/build/applications/task/t_SelectAnAppFromTheAppPicker.html

The server-side API debug log method available for scoped applications is gs.info(). This method logs informational messages that describe the progress of the application. Older methods such as gs.print() and gs.log() are not available in scoped applications. The gs.debuglog() method does not exist. The gs.info(), gs.warn(), gs.error(), and gs.debug() methods work in both scoped applications and global, and are therefore more versatile going forward in future versions. Reference: Debugging best practices

Inherited fields in ServiceNow are fields that are part of a parent table and automatically become part of child tables through inheritance. This structure is foundational in the ServiceNow data model, ensuring that child tables maintain a consistent relationship with their parent tables.

Here’s why inherited fields cannot be deleted from a child table:

System Design:ServiceNow employs a table inheritance model where child tables derive fields and properties from parent tables. Deleting inherited fields from a child table would break the integrity of the data model, as those fields are shared across multiple tables.

Impact on Functionality:Many inherited fields, such as sys_created_on or sys_updated_by, are integral to the functionality of the platform. Removing them could disrupt workflows, reporting, and auditing capabilities.

Alternative Approach:If you want to hide or restrict access to inherited fields in a child table, you can use ACLs (Access Control Lists) to prevent users from viewing or modifying these fields. Another option is to use UI Policies or Client Scripts to control their visibility on forms.

Developer Note:Attempting to delete inherited fields violates ServiceNow’s core principles of maintaining a robust and unified data structure. The platform enforces these rules to ensure consistent behavior across all tables in the hierarchy.

ServiceNow Developer Documentation on Table Inheritance​.

Best practices outlined on SN Pro Tips regarding scoped application development and table structures​.

The Create Branch operation is available from both Studio and the Git Repository. This operation allows you to create a new branch from an existing branch in your Git repository. You can use branches to work on different features or versions of your application without affecting the main branch. Reference: [Create a branch]

Creating applications in ServiceNow can help businesses replace outdated, inadequate, custom business applications and processes, extend service delivery and management to all enterprise departments, and extend the value of ServiceNow by leveraging its platform capabilities and integrations1234.

References = 1: What are Application Services? - ServiceNow 2: What is Application Development? - ServiceNow 3: Custom Applications in ServiceNow - The Cloud People 4: Build Custom Apps in ServiceNow – eBook – ServiceNow

The Bar Chart and Pie Chart report types can be created by right-clicking on a column header in a table’s list. These report types show how individual pieces of data relate to the whole using proportional bars or slices. You can also choose different aggregation methods such as count, sum, average, min, max, or percent. Reference: [Create reports from lists]

The welcome screen appears every time a new application is created through the Guided Application Creator. The welcome screen provides an overview of the steps involved in creating an application, such as defining the app name, scope, and tables, configuring the app user interface, and publishing the app. The other options are not true about the Guided Application Creator. The global scope option is turned off by default, as it is recommended to create applications in their own scope for better security and performance. A scope application user role is not automatically created, as the user can choose to create one or use an existing role for the app access control. Default access controls are not automatically created, as the user can define the read, write, create, and delete permissions for each table in the app. Reference: Guided App Creator

In ServiceNow Studio, delegated developers can work with update sets for assigned applications, but the mechanism for packaging changes for deployment is the Publish button. The Update Set Picker is used to switch between update sets, not to package the application changes. Export to XML is an administrative update set activity and is not the Studio control described in this question. Delegated development separates development and deployment permissions, so administrators can grant selected users permission to publish to an update set, application repository, or Store. For this question, the phrase “package changes for deployment” maps directly to the Publish button in Studio. Therefore, D is correct.

================

The source control operation used to store local changes on an instance for later application is called a stash. A stash is a temporary storage area for uncommitted changes that are not ready to be pushed to a remote repository. Developers can use stashes to save their work in progress without committing it to the local repository or discarding it. Stashes can be applied later to restore the changes to the working directory, or dropped if they are no longer needed. References: [ServiceNow Docs - Stash local changes], [ServiceNow Docs - Source control]

Administrators can grant non-admin users the ability to develop global applications. Delegated Development is for the scoped applications only

When creating a table in a privately-scoped application, four Access Controls are automatically created for the table. These Access Controls define the permissions for the four basic operations on the table: Create, Delete, Read, and Write. The Create operation allows the user to create new records on the table. The Delete operation allows the user to delete existing records on the table. The Read operation allows the user to view the records on the table. The Write operation allows the user to modify the records on the table. By default, these Access Controls grant access to the admin role and the application scope. You can modify or delete these Access Controls as needed.

The other options are not valid Access Controls for a table. Insert, Query, and Update are not operations, but methods of the GlideRecord class that are used to manipulate records on the server-side. They are not part of the Access Control rules.

To allow a module to open a form for new record insertion, the Link type should be set to “Create new record” or similar.

From Platform App Design Docs:

“Modules control navigation behavior via the Link type setting. To insert records, use the ' Create record ' or ' New record ' link type.”

Checkbox tooltip: " Show this module when the user has the specified roles. Otherwise the user must have the roles specified by both the application menu and the module. "

The following is true for the Override application menu roles configuration option when configuring a module:

Users with the module role but without access to the application menu access the module. This is true because the Override application menu roles option allows users to bypass the application menu role requirement and access the module directly if they have the module role. For example, if a module has the itil role and the Override application menu roles option enabled, and the application menu has the admin role, then a user who has the itil role but not the admin role can still access the module.

The following are not true for the Override application menu roles configuration option when configuring a module:

Self-Service users can access the module even though they do not have roles. This is false because the Override application menu roles option does not grant access to the module to users who do not have any roles. Self-Service users are users who do not have any roles assigned to them and can only access the Self-Service portal and the Knowledge Base. To access the module, users need to have at least the module role.

Admin is given access to the module even if Access Controls would ordinarily prevent access. This is false because the Override application menu roles option does not override the Access Control (ACL) rules that apply to the module. Access Control rules are used to restrict the access to the data and functionality of the ServiceNow platform based on the user’s roles and conditions. Admin is a role

The ServiceNow platform is designed to create applications that use forms, workflow, and reporting to solve business problems. Forms are used to interact with data stored in tables, workflow is used to automate and orchestrate processes, and reporting is used to visualize and analyze data. The platform does not require low-level programming libraries or multimedia features, as it provides standard tools and technologies for application development.

References = ServiceNow Certified Application Developer Exam Specification, Application Development Platform – ServiceNow

Global applications can use Automated Test Framework and Flow Designer features, but not Source Control and Delegated Development features. Source Control and Delegated Development features are only available to scoped applications . References: [Global vs Scoped Applications], [Delegated Development]

Flow Designer is a graphical tool that allows users to automate processes in ServiceNow without coding. The following are supported by Flow Designer:

Call a subflow from a flow. This is a feature that allows users to invoke a subflow, which is a reusable unit of logic, from a flow. This can help simplify complex flows and avoid duplication of logic.

Use Delegated Developer. This is a feature that allows administrators to delegate the development and maintenance of flows and actions to users who are not administrators. This can help distribute the workload and empower non-admin users to create automations.

Run a flow from a MetricBase Trigger. This is a feature that allows users to trigger a flow based on a MetricBase query, which is a way of analyzing time-series data in ServiceNow. This can help automate actions based on data trends and patterns.

The following is not supported by Flow Designer:

Test a flow with rollback. This is not a feature of Flow Designer, but of Automated Test Framework (ATF), which is a tool that allows users to create and run automated tests on ServiceNow applications and features. ATF supports testing flows with rollback, which means reverting any changes made by the flow during the test execution. References: Flow Designer, Automated Test Framework

Roles are used to control access to applications and modules in the application navigator. Each application menu or module has a role field that specifies which role is required to view it. Users who do not have the specified role or a role that contains it will not see the application menu or module. Roles can also be used to control access to other features and capabilities in ServiceNow, such as tables, fields, scripts, and workflows.

References = Enable or disable an application menu or module, Grant a role access to applications and modules, Controlling access to applications and modules.

https://docs.servicenow.com/bundle/tokyo-application-development/page/script/server-scripting/concept/c_ServerScripting.html

In ServiceNow, the Event Registry is a table that contains a record for every event recognized by the system. It allows ServiceNow to respond when these events are generated. By registering events, the system can automate activities such as triggering notifications or executing script actions when specific events occur. Therefore, the correct answer is A.

The other options are not accurate descriptions of the Event Registry:

B. The Event Log which lists all Events that have been generated: This describes the Event Log, not the Event Registry.

C. A Workflow which is launched every time an Event is generated; used to debug Events: This is not how the Event Registry functions.

D. The method used in server-side scripts to generate Events and pass parameters: This describes the gs.eventQueue() method, not the Event Registry.

For more detailed information, refer to the official ServiceNow documentation on the Event Registry.

https://docs.servicenow.com/bundle/tokyo-servicenow-platform/page/administer/notification/task/t_CreateANotification.html

https://developer.servicenow.com/dev.do#!/learn/learning-plans/quebec/new_to_servicenow/app_store_learnv2_automatingapps_quebec_when_to_send

The Weight field in an Email Notification determines which notification is sent when multiple notifications are triggered for the same record and recipients. Only the notification with the highest weight is sent. A weight value of zero means the notification is always sent when the notification’s When to send criteria is met. A weight value of -1 means that no email should be sent3. References: Email Notification Weight

Options for Creating Tables in Guided Application Creator:

Create a table from scratch: This option allows you to define a completely new table with custom fields and configurations.

Create a table from a template: You can use predefined table templates to speed up table creation. Templates often include pre-configured fields and settings.

Extend a table: This allows you to create a new table by inheriting fields and functionality from an existing table, enabling reuse and consistency.

Why Other Options Are Incorrect:

Option A (Link to external tables): Linking to external tables is not an option provided in the Guided Application Creator; external data is typically accessed through integration methods.

Option D (Run import jobs): Import jobs are used for data migration, not for table creation in the Guided Application Creator.

Option E (Upload a spreadsheet): While uploading a spreadsheet can create tables, this is a feature of Import Sets, not the Guided Application Creator.

Option F (Use API calls): API calls are for integration and not an option for creating tables directly in the Guided Application Creator.

ServiceNow Developer Documentation on Guided Application Creator​.

https://docs.servicenow.com/bundle/tokyo-application-development/page/app-store/dev_portal/API_reference/GlideQuery/concept/GlideQueryGlobalAPI.html#GlideQueryAPI

https://docs.servicenow.com/bundle/tokyo-application-development/page/app-store/dev_portal/API_reference/glideRecordScoped/concept/c_GlideRecordScopedAPI.html

Application Access on a table defines cross-scope behavior at the table boundary. To ensure that no other application scope can create records on the application’s data tables, the table must be restricted so that only the owning scope can access it. Setting Accessible from to This application scope only enforces that boundary by preventing other scoped applications from accessing the table, including record creation. This is exactly what the requirement describes: blocking other private scopes from creating records on the table. The “All application scopes” option is the opposite of what you want because it opens cross-scope access, and then trying to selectively block “Can create” still leaves broader exposure and is not aligned with the stated goal. Creating ACLs to block other scopes is also not the correct approach for cross-scope isolation because ACLs primarily control user and role access, while cross-scope access is governed by Application Access and cross-scope rules. Disabling “Allow access to this table via web services” is about API/web service exposure, not about other application scopes creating records through normal platform access.

In ServiceNow, to include data from another table within a form, the Reference field type is utilized. A Reference field creates a relationship between the current table and another table by storing a reference to a record in the target table. This allows users to select a record from the referenced table and display related information seamlessly within the form.

A. Use the Date field type: This is incorrect. The Date field type is designed to store date values and does not facilitate referencing records from other tables.

B. Use the Phone Number field type: This is incorrect. The Phone Number field type is intended for storing phone number data and does not support referencing other table records.

C. Use the String field type: This is incorrect. The String field type stores text data and does not inherently provide functionality to reference records from other tables.

D. Use the Reference field type: This is correct. The Reference field type is specifically designed to create a link to a record in another table, enabling the incorporation of related data into the form.

For example, in the Incident table, the " Caller " field is a reference to the User [sys_user] table, allowing the selection of a user as the caller for the incident. This setup ensures data consistency and leverages existing records without data duplication.

For more detailed information, refer to the official ServiceNow documentation on Reference Fields.

In ServiceNow, Modules are navigation elements that provide access to various parts of the platform, such as forms, lists, reports, or other application components. They are organized within Application Menus to create a structured and intuitive navigation hierarchy.

Key characteristics of Modules:

Part of Application Menus: Every module is contained within an application menu. This organization helps users navigate to different areas of the platform efficiently. For instance, the " Incident " application menu may contain modules like " Create New " or " All Incidents. "

Functionality: Modules can open various elements, including forms, lists, reports, or URLs. This flexibility allows modules to direct users to specific records, filtered lists, or external resources.

Association with Tables: While many modules are associated with specific tables (e.g., a module that displays a list of incidents is associated with the " Incident " table), it ' s not a strict requirement. Some modules may link to external URLs or perform actions not directly tied to a table.

Access Control: Access to modules is controlled through roles. Administrators can define which user roles have visibility and access to specific modules, ensuring that users only see modules relevant to their responsibilities.

For example, a module named " Active Incidents " under the " Incident " application menu might display a list of all active incident records. Access to this module can be restricted to users with the " itil " role, ensuring that only authorized personnel can view active incidents.