Free Practice Questions for ServiceNow CAD Exam

In ServiceNow, a Record Producer is a specific type of catalog item that enables users to create task-based records through a simplified interface.

servicenow.com

To create a module that directs users to a Record Producer UI:

Link Type Selection: Choose "URL (from Arguments:)" as the Link Type. This option allows you to specify a direct URL, enabling the module to open the desired Record Producer interface.

URL Configuration: In the "Arguments" field, input the URL that points directly to the Record Producer. This URL typically follows the format:

/record_producer.do?sys_id=

Replace with the actual sys_id of the Record Producer you intend to open.

By configuring the module this way, users accessing it will be presented with the Record Producer's user-friendly interface, facilitating the creation of new records without navigating through the standard form UI.

Business Rule is server-side, so it uses GlideSystem API. gs.hasRoleExactly doesn't exist

In a Business Rule, the following returns true if the currently logged in user has the admin role:

gs.hasRole(‘admin’). This is the correct answer because gs is the GlideSystem object, which provides methods for performing system operations, and hasRole is a method that checks if the current user has the specified role. For example, gs.hasRole(‘admin’) will return true if the current user has the admin role, and false otherwise.

The following do not return true if the currently logged in user has the admin role in a Business Rule:

g_form.hasRoleExactly(‘admin’). This is not correct because g_form is the GlideForm object, which provides methods for manipulating forms, and hasRoleExactly is a method that checks if the current user has exactly the specified role and no other roles. For example, g_form.hasRoleExactly(‘admin’) will return true if the current user has only the admin role, and false if the current user has the admin role and any other role.

g_form.hasRole(‘admin’). This is not correct because g_form is the GlideForm object, which provides methods for manipulating forms, and hasRole is a method that checks if the current user has the specified role or any role that contains the specified role. For example, g_form.hasRole(‘admin’) will return true if the current user has the admin role or any role that contains the admin role, such as admin_ui or admin_script.

gs.hasRoleExactly(‘admin’). This is not correct because gs is the GlideSystem object, which provides methods for performing system operations, and hasRoleExactly is not a valid method of the gs object. There is no method that checks if the current user has exactly the specified role and no other roles in the gs object. References: Business Rules, GlideSystem, GlideForm

"You must first select read access to grant any other API record operation." https://docs.servicenow.com/bundle/tokyo-application-development/page/build/applications/reference/r_TableApplicationAccessFields.html

The Application Access configuration fields control the access level for an application and its tables. The following Application Access configuration fields are not available if the Can read configuration field is not selected:

Can create. This field determines whether users can create records on the application tables.

Can update. This field determines whether users can update records on the application tables.

Can delete. This field determines whether users can delete records on the application tables.

These fields are not available because they depend on the Can read field, which determines whether users can view records on the application tables. If users cannot read records, they cannot create, update, or delete them either.

The following Application Access configuration fields are available regardless of the Can read configuration field:

All access to this table via web services. This field determines whether users can access the application tables using web services, such as REST or SOAP.

Allow configuration. This field determines whether users can configure the application tables, such as adding or modifying fields, views, or indexes. References: Application Access, Certified Application Developer (CAD) Learning Path

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.

An example of when an application might not use a Scheduled Script Execution (Scheduled Job) is when the application needs to run a client-side script at the same time every day. A Scheduled Script Execution is a server-side script that runs on a specified schedule and performs some action on the server or database. A client-side script runs on the user’s browser and cannot be scheduled by ServiceNow. The other options are examples of when an application might use a Scheduled Script Execution, such as sending email reminders, running a clean up script, or querying the database for unassigned records. Reference: Scheduled Script Execution, Client scripts

To see what scripts, reports, and other application artifacts will be in a published application, the best option is to examine the Application Files Related List in the application to be published. This will show all the application files that belong to the application, grouped by file type and scope. You can also filter, sort, or search the list to find specific files.

The following options are not the best ways to see what application artifacts will be in a published application:

Enter the name of the Application in the Global search field. This will perform a global text search on the instance and return any records that match the application name, which may include irrelevant or incomplete results.

Open the list of Update Sets for the instance. This will show all the update sets that have been created or imported on the instance, but not necessarily the ones that belong to the application to be published. Update sets are used to move customizations between instances, not to publish applications to the ServiceNow Store or Share.

Open the artifact records individually to verify the value in the Application field. This will require opening each record that may be part of the application and checking the Application field, which is tedious and error-prone. References: Publish an Application, Application Files

The syntax used in a Record Producer script to access values from Record Producer form fields is producer.variable_name. A Record Producer is a type of catalog item that allows users to create records on any table from the service catalog. A Record Producer script is a server-side script that runs when a Record Producer is submitted, and can be used to set values or perform actions on the generated record. The producer object is a global object that represents the Record Producer form and its variables. The variable_name is the name of the variable defined in the Record Producer. References: [ServiceNow Docs - Record producers], [ServiceNow Docs - Record producer script]

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

The application name is not required to link a ServiceNow application to a Git repository. You only need to provide the URL, user name, and password of the Git repository, as well as the branch name and the authentication type. The application name is automatically generated based on the scope name of your application. Reference: [Link an application to a Git repository]

In ServiceNow, the Application Picker is a tool that allows developers to select the active application scope. When an application is selected from the Application Picker, it sets the Application Scope to that application. This means that any configurations, scripts, or customizations made will be associated with the selected application's scope. Therefore, the correct answer is D.

The other options are incorrect:

A. Selecting Global in the Application Picker sets the Application Scope to Incident: Selecting "Global" sets the scope to the global application, not specifically to Incident.

B. Global is a reserved application which does not appear in the Application Picker: The Global application does appear in the Application Picker and can be selected.

C. Selecting an application from the Application Picker does not set the Application Scope: Selecting an application does set the Application Scope.

For more detailed information, refer to the official ServiceNow documentation on Application Scope.