Pass the ServiceNow Certified Application Developer CAD Questions and answers with CertsForce

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

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

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 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]

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.

In ServiceNow, when developing within a privately-scoped application, certain logging methods are recommended for use in server-side scripts to ensure proper logging and debugging. The GlideSystem (gs) object provides several methods for this purpose:

gs.debug():

Description: Logs messages at the "Debug" level.

Usage: gs.debug('Debug message here');

Purpose: Useful for logging detailed information during development and troubleshooting. These messages are typically only visible when the system's logging level is set to "Debug."

gs.error():

Description: Logs messages at the "Error" level.

Usage: gs.error('Error message here');

Purpose: Used to log error messages that indicate a problem that might still allow the application to continue running.

gs.warn():

Description: Logs messages at the "Warning" level.

Usage: gs.warn('Warning message here');

Purpose: Used to log potentially harmful situations that are not necessarily errors but may require attention.

gs.info():

Description: Logs messages at the "Information" level.

Usage: gs.info('Information message here');

Purpose: Used to log informational messages that highlight the progress of the application at a coarse-grained level.

Deprecated or Unsupported Methods in Scoped Applications:

gs.log():

Description: This method is not supported in scoped applications. It is restricted to the global scope and is not accessible from a private scope. Therefore, it should be avoided in privately-scoped applications.

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

A workflow is a tool that allows you to automate processes on the ServiceNow platform. A workflow consists of activities and transitions that define the logic and flow of the process. A workflow context is an instance of a workflow that is generated from a workflow version, executes activities, and follows transitions. A workflow context is associated with a specific record on a table and tracks the state and progress of the workflow. You can view and manage the workflow contexts from the Workflow Contexts module or the Workflow Contexts related list on a record.

The other options are not valid definitions of a workflow context. A checked out workflow is a workflow that is being edited by a user and has not been published yet. The table and conditions for a workflow are the criteria that determine when a workflow should run on a record. The business reason or process for a workflow is the purpose and function of the workflow.

https://developer.servicenow.com/dev.do#!/learn/courses/sandiego/app_store_learnv2_learnmore_sandiego_learn_more/app_store_learnv2_learnmore_sandiego_form_and_list_layouts/app_store_learnv2_learnmore_sandiego_what_is_form_designer

The Form Designer is a tool that allows you to create and customize forms on the ServiceNow platform. The Form Designer has four main components:

Form layout: The form layout shows the preview of the form and allows you to drag and drop fields, sections, and related lists onto the form. You can also resize, reorder, and delete the elements on the form layout.

Page header: The page header shows the name of the table and the form that you are editing. You can also access the form properties, save the form, and switch to the form view from the page header.

Field navigator: The field navigator shows the list of available fields for the table and allows you to search, filter, and add fields to the form. You can also create new fields and edit existing fields from the field navigator.

Schema map: The schema map is not part of the Form Designer. The schema map is a separate tool that shows the relationships between tables and fields on the platform. You can access the schema map from the System Definition > Tables module or from the context menu of a table.

https://docs.servicenow.com/bundle/tokyo-platform-security/page/administer/contextual-security/concept/access-control-rules.html