Free CIS-ITSM Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

A Problem Task (problemtask) is a child record created from a parent Problem record to break down and assign the work required for investigation and resolution. The Problem Task table contains a reference field named 'Problem' that links it directly to the parent Problem record. This structure allows for the organized management of activities such as root cause analysis or implementing a permanent fix, all under the umbrella of the single parent problem.

A. Workaround: A workaround is a field containing descriptive text on the Problem record itself; it is not a separate child record.

B. Related Incidents: Incidents are linked to a problem, but they are typically the source of the problem, not child records created to manage the problem's resolution.

D. Known Error: A Known Error is a state within the problem lifecycle or a related knowledge base article created from the problem, not a direct child task record.

E. Major Incident: A Major Incident is a type of incident that can trigger the creation of a problem; it is a precursor, not a child record.

1. ServiceNow Product Documentation

"Problem Management": "A problem task is a task that is created to perform a piece of work that is required to complete a problem." This documentation explicitly defines the relationship where problem tasks are created to complete a problem. See the "Problem tasks" section within the Problem Management documentation for the Rome

San Diego

Tokyo

or later releases.

2. ServiceNow Product Documentation

"Create a problem task": The procedure for creating a problem task involves navigating to an existing problem record and adding a new problem task from the 'Problem Tasks' related list. This workflow demonstrates the direct parent-child relationship. See the "Create a problem task" procedure in the Problem Management documentation.

3. ServiceNow Developer Documentation

"Table: Problem Task [problemtask]": The schema for the problemtask table shows a column named problem which is a direct reference to the problem table. This database-level reference establishes the parent-child link. This can be verified by navigating to System Definition > Tables and viewing the columns for the problemtask table in a ServiceNow instance.

:

The CI Class Manager is the centralized and primary tool within ServiceNow for managing the Configuration Management Database (CMDB) model. It provides a hierarchical, tree-view display of all Configuration Item (CI) classes, showing their parent-child inheritance relationships. Administrators use this interface to explore the entire class structure, view and edit class definitions (including attributes and rules), and create new classes. It is specifically designed to provide a comprehensive overview of the CMDB's underlying table structure and definitions, making it the correct tool for the task described.

A. Application Menus are used for navigating to application modules, lists, and forms to interact with data records, not for exploring the underlying class model hierarchy.

B. A Report is a tool for creating visualizations and analyzing data contained within tables, not for examining the architectural definition or hierarchy of the tables themselves.

C. The Dependency view is a graphical map that shows the operational relationships between specific, individual Configuration Items (CIs), not the class structure of the entire CMDB.

1. ServiceNow Product Documentation: "CI Class Manager". The documentation states

"Use the CI Class Manager to explore

and manage CI classes in a hierarchy display. The CI Class Manager provides a centralized place to create and edit CI classes

and to view all the details of a class

such as its attributes

identification rules

and identifier entries." (ServiceNow

Tokyo Release

CMDB and CSDM

CMDB tables and the CI Class Manager).

2. ServiceNow Now Learning: "CMDB Fundamentals - On Demand". In the "CMDB Data Model" module

the course material explains

"The CI Class Manager provides a centralized place to... view a list of all CI classes in a tree-view hierarchy." This confirms its purpose as the tool for exploring the class hierarchy. (ServiceNow

Now Learning

Course ID: SN-CMDBF).

Performance Analytics (PA) is designed to track and analyze trends over time, often using complex calculations and data from multiple snapshots. Standard ServiceNow reporting, in contrast, queries the live database to show the current state of data.

The metrics "% Successful Changes" and "% Unauthorized Changes" are classic Key Performance Indicators (KPIs) that measure process quality and compliance. They require calculations based on historical data and potentially complex logic (e.g., correlating CI updates to approved changes) that are beyond the scope of standard, real-time reporting. These are provided out-of-the-box with the Performance Analytics Content Pack for ITSM.

B. Count of Completed Changes per Month, by Change Type: This is a simple aggregation of current records, grouped by a field. This is a standard function easily created using the ServiceNow Report Designer.

D. Count of Completed Changes per Month, by Category: Similar to option B, this is a straightforward count of records based on current data, which is a core capability of standard ServiceNow reporting.

1. ServiceNow Product Documentation - Performance Analytics for Change Management: This document lists the out-of-the-box indicators available with the PA content pack for ITSM. It explicitly includes indicators for tracking unauthorized and successful changes.

Reference: ServiceNow Product Documentation > Performance Analytics and Reporting > Performance Analytics > Dashboards > ITSM PA dashboards > Change Management dashboard > Change Management dashboard indicators. The indicators Change.Successful (Percentage of successful changes) and Change.Unauthorized (Number of unauthorized changes

used to calculate the percentage) are listed as preconfigured PA indicators.

2. ServiceNow Product Documentation - Reporting vs. Performance Analytics: This documentation clarifies the distinction between the two tools. Reporting provides real-time

operational views of current data

while Performance Analytics tracks trends and KPIs over time using historical data snapshots.

Reference: ServiceNow Product Documentation > Performance Analytics and Reporting > Getting Started > Reporting and Performance Analytics > Reporting vs. Performance Analytics. This section states

"Performance Analytics is a good solution for tracking KPIs... Reporting is a good solution for... finding the current count of open incidents assigned to a particular group." This supports that simple counts (B

D) are for Reporting

while KPIs (A

C) are for PA.

ServiceNow's conflict detection mechanism identifies potential scheduling issues by checking for other changes or maintenance windows affecting the same Configuration Item (CI) during the same time frame. The system specifically evaluates three key fields on the Change Request form to determine a conflict: the 'Configuration item' to identify the asset being changed, and the 'Planned start date' and 'Planned end date' to define the change window. A conflict is flagged if another change is scheduled for the same CI within an overlapping time period.

C. CI Business criticality: This field indicates the importance of the CI to the business but is not a direct input for the scheduling conflict detection logic.

E. Risk: The Risk field is an output of a risk assessment or a manually set value; it does not serve as an input for identifying scheduling conflicts with other changes.

1. ServiceNow Product Documentation - Change conflict detection: "The conflict check is based on the Configuration item

Planned start date

and Planned end date fields on the Change Request form. A conflict exists if the change request configuration item is included in another change request in the same time period." (ServiceNow. (2024). Change conflict detection. Product documentation. Washington DC release.)

2. ServiceNow Product Documentation - Detect change conflicts: "Conflict detection looks for conflicts with other change requests or with blackout or maintenance windows. A conflict is detected if the current change is scheduled for the same configuration item during the same time as another change." (ServiceNow. (2024). Detect change conflicts. Product documentation. Washington DC release.)

The question asks for the available options in the 'Release phase' choice list on a Release record. While the base Release record has simpler phases, the options provided are specific to a software release managed via the Software Development Life Cycle (SDLC) model. For an SDLC Release record (rmreleasesdlc), ServiceNow provides a more granular set of default phases that align with standard software development practices. These default choices are Requirement Gathering, Design, Development, Build, Deployment, QA, and User Acceptance, which directly correspond to the list in option D.

A. Requirement Gathering, Design, Build, Roll-out, Unit Testing, User Acceptance, Pilot: This option is incorrect because it presents an illogical sequence, placing "Roll-out" (a deployment activity) before essential testing phases like "Unit Testing" and "User Acceptance".

B. Scoping, Design, Develop, Deployment, Unit Testing, Integration, Pilot: This option is incorrect. While the terms are related to SDLC, it improperly places "Deployment" before "Unit Testing" and "Integration" testing, which must precede deployment.

C. Analyze, Design, Development, Build, Roll-out, QA, User Acceptance: This option is incorrect as it illogically places "Roll-out" (deployment) before the "QA" and "User Acceptance" testing phases, which are critical pre-deployment validation steps.

1. ServiceNow Product Documentation: The default choice list for the phase field on the Software Release table (rmreleasesdlc) includes these specific values. This can be verified by inspecting the dictionary entry for rmreleasesdlc.phase in a base instance. The documentation for the SDLC plugin outlines these distinct stages. (ServiceNow Documentation

Release Management

"Create a software release" section).

2. ServiceNow Developer Documentation: The system dictionary for the rmreleasesdlc table defines the choices for the phase field. The default values are: requirementgathering

design

development

build

deployment

qa

and useracceptance. This directly validates the components of the correct answer. (ServiceNow Developer Site

Table: rmreleasesdlc

Column: phase).

3. University Courseware: Standard software engineering curricula confirm these phases as fundamental to the SDLC. For example

course materials on software engineering describe a waterfall or iterative model that includes requirements analysis

design

implementation (development/build)

testing (QA/UAT)

and deployment. (See

for example

MIT OpenCourseWare

6.170 Software Studio

which outlines similar lifecycle phases).

A Content Item is a specific type of catalog item designed to provide information rather than a requestable good or service. It is the correct choice for creating a link in the Service Catalog that redirects a user to a Knowledge Base article, an external URL, or displays static content. This directly fulfills the requirement of a "View Company Policies" link that points to an existing knowledge article.

B. Record Producer: This is used to create a task-based record, such as an incident or a change request, not to link to informational content.

C. Knowledge Item: This is not a standard, out-of-the-box record type for the Service Catalog in ServiceNow.

D. Order Guide: This is used to bundle multiple, related catalog items into a single request process for a more complex fulfillment.

E. Catalog Item: While a Content Item is a type of catalog item, this option is too generic. The most precise answer for linking to information is "Content Item".

1. ServiceNow Product Documentation - Create a content item: "Content items can have a content type of External Content

Knowledge Base

or Catalog Content. For a content item with a content type of Knowledge Base

you can select a knowledge base and an article from that knowledge base." (ServiceNow Product Documentation

Washington DC Release

Document ID: cCreateAContentItem.html).

2. ServiceNow Product Documentation - Types of catalog items: "Content item: Allow you to provide information instead of goods or services. For example

you can create a content item that provides a link to a password reset tool or a knowledge article." (ServiceNow Product Documentation

Washington DC Release

Document ID: cTypesOfCatalogItems.html).

The Change Interceptor is the default ServiceNow user interface element that appears when a user clicks "Create New" within the Change Management application, provided the instance has not been configured to use the newer Change Landing Page. Its purpose is to "intercept" the creation process and prompt the user to select a specific type of change (e.g., Normal, Standard, or Emergency). This selection then directs the user to the appropriate form for that change type. Since the scenario explicitly states that the instance has not migrated to multimodal change (which uses the Change Landing Page), the legacy interceptor behavior remains the default.

B. Change Form: This is the detailed view for a specific change record, which is displayed only after a change type has been selected from the interceptor.

C. Change Landing Page: This is the user interface for the multimodal change experience, which the question explicitly states the instance has not been migrated to.

D. Change Overview: This is typically a dashboard or homepage module that displays reports and key metrics, not a page for initiating a new record.

1. ServiceNow Product Documentation - Interceptors: "An interceptor is a page that is displayed when you navigate to a URL... The Change Request application uses an interceptor to prompt users to select the type of change to create

such as emergency

normal

or standard." This document confirms the function and default use of the interceptor for Change Management. (ServiceNow Product Documentation

Vancouver Release

Platform administration > UI and pages > Interceptors).

2. ServiceNow Product Documentation - Configure the Change Management landing page: "The Change Management landing page provides a single place for a change user to select the required change type and create a change request... By default

the Change Management landing page is enabled. If you want to revert to the classic change creation process

you can disable the landing page." This documentation clarifies that the Landing Page is the newer model and that a "classic" process (the interceptor) exists as the alternative. (ServiceNow Product Documentation

Vancouver Release

ITSM > Change Management > Administration > Configure the Change Management landing page).

The itiladmin role inherits several granular administrative roles, including changemanager. The changemanager role is specifically designed to configure and oversee the Change Management application. This responsibility includes managing the risk calculation framework by defining Risk Conditions and configuring Risk Assessments to determine when specific assessments are triggered. Furthermore, this role holds elevated privileges for data management within the application, such as the ability to delete change request records, a task that standard itil users cannot perform. These three functions are core administrative and support tasks for the Change Management process, directly aligning with the purpose of the itiladmin role.

B. Delete CAB Definition: While the changemanager role technically possesses the Access Control List (ACL) permissions to delete CAB definitions, this is a high-impact action on a core process configuration. In practice, such structural changes are often reserved for the full admin role to prevent accidental disruption of the change process.

E. Create and manage Approval Policies: Modern ServiceNow instances manage approval policies primarily through Flow Designer. Creating and managing these policies requires roles like flowdesigner or approvaladmin, which are not contained within the itiladmin role. The itiladmin role's ability is limited to legacy approval rule types.

1. ServiceNow Product Documentation - Roles in Change Management: The documentation explicitly states that the itiladmin role contains the changemanager role. The changemanager role is described as having permissions to "manage change risk assessments and conditions" and "delete change requests."

Reference: ServiceNow Documentation

Quebec Release

"Roles installed with Change Management

" Section: changemanager.

2. ServiceNow Product Documentation - Configure risk assessment and risk calculation: This document details the configuration of risk assessments and risk conditions. It specifies that the changemanager role is required to create and modify the riskassessment and riskconditions records

which corresponds to managing these features.

Reference: ServiceNow Documentation

Utah Release

"Configure risk assessment and risk calculation for Change Management."

3. ServiceNow Product Documentation - Change approval policies: This documentation outlines that Change Management approval policies define the approvals required for a change. It also notes the transition to using Flow Designer for approvals

stating

"You can use the ServiceNow® Flow Designer to create and manage approval policies." Access to Flow Designer is governed by the flowdesigner role

not itiladmin.

Reference: ServiceNow Documentation

Washington D.C. Release

"Change approval policies."

State Flows are a core component of the ServiceNow Change Management State Model. This functionality allows an organization to define and customize the lifecycle for different change models (e.g., Normal, Standard, Emergency). Administrators can configure the specific states and, crucially, the condition-based transitions between those states. This ensures that each type of change follows a "fit-for-purpose" process flow, moving from one state to another only when specific conditions are met.

A. Workflows 2 0: This is not a valid or official ServiceNow term. While workflows and Flow Designer are used for automation, this is not the name of the feature.

B. Stale Transition Models: This is an incorrect term. "Stale" implies something is outdated, which is contrary to the purpose of a flexible, condition-based model.

C. Conditional Change Models: While the concept involves conditions, this is not the official terminology ServiceNow uses for the feature that defines state transitions and flows.

---

1. ServiceNow Product Documentation - State model and transitions for Change Management: "The Change Management state model allows you to customize the change process by modifying or adding states and defining the rules for moving between states... The state model functionality is available by default for Normal

Emergency

and Standard change models." This document details how state flows (smstateflow table) define the sequence of states for a specific model.

2. ServiceNow Product Documentation - Change Management - State Model: "The Change Management - State Model plugin (com.snc.change.statemodel) is activated by default. This plugin enables you to customize the change process by modifying or adding states and defining the rules for moving between states." This confirms the feature is a core

named plugin for this exact purpose.

In the ServiceNow Now Platform, a View is a specific user interface (UI) layout for a form or a list. Views allow administrators to define alternative arrangements of fields, sections, and related lists for the same data table. This enables the creation of tailored experiences for different user personas, processes, or interfaces. The examples provided—Default, Major incidents, Self Service, and Mobile—are all standard names for different form views that present the same underlying record in a way that is most relevant to a specific context or user role.

A. Forms: A form is the entire UI for displaying a single record. A view is a specific layout of that form, not the form itself.

B. Form Designs: Form Design is a modern UI Builder tool used to configure form layouts and views, not the name of the resulting layout.

C. Form Layouts: Form Layout refers to the specific arrangement of fields on a form for a given view; it is the configuration of a view.

E. Workspaces: A Workspace is a comprehensive, role-based UI that contains various components, including forms that themselves use different views.

1. ServiceNow Product Documentation - Views: "A view defines the elements that appear on a form or a list. For different users

you can display different views for the same form or list... For example

you can create a view of the Incident form that is used only by major incident managers. You can create another view of the Incident form that is used by self-service users." This document also explicitly mentions the "Default view" and "Self-service view". (ServiceNow Product Documentation

Utah release

"Views"

DOC1538198).

2. ServiceNow Developer Documentation - UI16 Form Views: "Form views are alternate form layouts. Create form views to show or hide fields on a form to provide a different user experience for the same form. For example

the Incident form has different form views for default users (itil role) and for Self-Service users (no role)." (ServiceNow Developer Site

"UI16 Form Views"

developer.servicenow.com).

3. ServiceNow Product Documentation - Form configuration: "You can customize forms to show the information that your users need. One way to do this is by creating different form views." (ServiceNow Product Documentation

Utah release

"Form configuration"

DOC1538197).

The requirement to automatically close open Incident Tasks when a parent Incident is closed or canceled is controlled by a specific system property. This property can be set in two primary ways:

1. Navigating to Incident > Administration > Incident Properties and setting the option labeled "Close open Incident Tasks when Incident is closed or canceled" to Yes.

2. Directly modifying the system property com.snc.incident.incidenttask.closure to true in the System Properties [sysproperties] table.

Both methods achieve the same outcome by enabling the business rule named "Close Incident Tasks".

C. The property com.snc.incident.autoclose.basedon.resolvedat is used to automatically close Incidents that have been in a 'Resolved' state for a specified duration, not to close child Incident Tasks.

D. "Autoclose Incident Tasks" is not the correct label for the setting within the Incident Properties module. The official label is more descriptive, as stated in option A.

1. ServiceNow Product Documentation: Incident Management properties. This document details the available properties for the Incident Management application. It explicitly lists the property with the label "Close open Incident Tasks when Incident is closed or canceled" and its corresponding system property name com.snc.incident.incidenttask.closure. The description confirms its function: "If set to true

all open incident tasks are closed when the incident is closed or canceled."

2. ServiceNow Product Documentation: Configure Incident Management. This guide provides an overview of configuring Incident Management

including navigating to the Incident Properties page where the relevant setting is located. (Section: "Configure Incident Management properties").

The problemadmin role is required to delete problem records in ServiceNow. This role provides administrative-level access to the Problem Management application, including the ability to manage properties and perform destructive actions like deleting problem, problem task, and known error article records. This privilege is intentionally separated from process-focused roles like problemmanager or problemcoordinator to prevent accidental data loss and maintain data integrity. The user in the scenario requires this specific administrative role to clean up the accidentally created records.

B. problemcoordinator: This role is responsible for managing and working on problem tasks but lacks the administrative rights to delete entire problem records.

C. soproblemdelete: This is not a standard, out-of-the-box role provided with the ServiceNow Problem Management application.

D. RHmanager: This is not a recognized base system role within the ServiceNow ITSM suite and is irrelevant to Problem Management.

E. problemmanager: This role oversees the Problem Management process but, by default, does not have permissions to delete problem records; this is reserved for the problemadmin.

1. ServiceNow Product Documentation (Washington DC): Components installed with Problem Management. This official document explicitly states the function of the problemadmin role: "Can manage all problem management properties

and can delete problem

problem task

and known error article records." The descriptions for problemmanager and problemcoordinator do not include deletion privileges.

2. ServiceNow Product Documentation (Washington DC): Problem Management roles and personas. This guide outlines the responsibilities for each role

confirming that administrative tasks

including deletion

are assigned to the problemadmin persona

distinct from the process-focused problemmanager and problemcoordinator personas.

When a catalog item is published using the Catalog Builder, ServiceNow automatically creates a local update set to capture the configuration. The naming convention for this update set is standardized to ensure clarity and trackability. The format used is Catalog item - - , which explicitly includes the name of the catalog item being published and the specific date and time of the publication event. This automated naming helps administrators easily identify the contents and version of the update set.

B. item author: The author's name is not part of the automatically generated update set name, although the author is tracked on the update set record itself.

C. variables: Variables are captured as configuration records within the update set, not as part of its name.

D. catalog(s): The catalog(s) to which the item belongs are not included in the update set's name.

1. ServiceNow Product Documentation: "Publish a catalog item". In the section detailing the publishing process from Catalog Builder

the documentation states: "When you publish a catalog item

a corresponding update set is created with the name Catalog item - - ." This is found under the Service Catalog > Catalog Builder documentation for recent ServiceNow releases (e.g.

Washington DC

Vancouver).

A Dynamic CI group is the appropriate ServiceNow feature for this requirement. It allows for the creation of a collection of Configuration Items (CIs) based on a set of filter conditions defined in an encoded query. In this scenario, the criteria would be Class is Web Server AND Location is Miami. The group's membership is automatically updated whenever CIs are created or modified to match or no longer match these criteria, ensuring the group remains accurate without manual maintenance. This functionality is essential for managing and reporting on specific subsets of CIs within the CMDB.

A. CI class: A CI class is a type or category of a configuration item (e.g., Web Server), not a specific, filter-based grouping of instances with shared attributes like location.

B. Dependent group: This is not a standard ServiceNow term for this function. CI relationships are defined through dependency maps, not a feature called a "dependent group."

C. CSDM component group: This is not a recognized term within the Common Service Data Model (CSDM) or ServiceNow. CSDM uses Application Services to group CIs that constitute a service.

1. ServiceNow Product Documentation (Utah): Dynamic CI groups. "A dynamic CI group is a CI group that is populated with CIs by a CMDB group query... The query runs against a target CMDB class and its child classes

and the CIs that the query returns become members of the CI group." This directly describes the functionality needed to group all web servers in Miami.

2. ServiceNow Product Documentation (Utah): Create a dynamic CI group. The procedure outlines the steps: "Navigate to Configuration > CI Groups. Click New. On the form

fill in the fields. In the Type field

select Dynamic CI Group. In the CI filter field

create the filter to use for the query that populates the group." This confirms the mechanism for creating such a group.

Catalog Builder is the modern, recommended tool for creating and editing service catalog items, including record producers like "Create Incident." It provides a visual, guided experience for managing the item's details, adding and configuring variables (which appear as input fields or questions to the user), and defining the fulfillment process. Using Catalog Builder is the standard best practice for modifying baseline catalog items to meet customer requirements for additional information gathering.

B. Edit in Item Designer: Item Designer is a legacy tool that has been largely superseded by the more powerful and flexible Catalog Builder. It is not the recommended tool for this task.

C. Edit in Catalog Item Designer: This is not a valid tool name within the ServiceNow platform and serves as a distractor option.

D. Edit in Form Designer: Form Designer is used to configure the layout of fields on a record's form (e.g., the incident form itself), not for adding user-facing input fields (variables) to a catalog item.

1. ServiceNow Product Documentation - Catalog Builder: "You can create or edit catalog items using a visual and guided experience in Catalog Builder. You can delegate the catalog item creation and maintenance to non-administrators." This document explicitly states Catalog Builder is used to edit items.

Source: ServiceNow Product Documentation

"Catalog Builder

" Quebec release and later.

2. ServiceNow Product Documentation - Create a record producer: "You can create and edit record producers in Catalog Builder. You can also create a record producer by navigating to Service Catalog > Catalog Definition > Record Producers and clicking New." This confirms that Catalog Builder is a primary tool for editing record producers.

Source: ServiceNow Product Documentation

"Create a record producer

" Washington DC release.

3. ServiceNow Now Learning - Service Catalog Fundamentals: The courseware demonstrates that Catalog Builder is the primary interface for adding "questions" (variables) to a catalog item. The "Questions" tab within the Catalog Builder UI is where an administrator or catalog manager would add the requested input fields.

Source: ServiceNow Now Learning

"Service Catalog Fundamentals" course materials

Module: "Create and Edit Catalog Items."

4. ServiceNow Product Documentation - Form design: "Form design enables administrators to create and edit form layouts... You can change what appears on a form

such as fields

sections

and related lists." This reference clarifies that Form Designer's scope is the backend form layout

distinct from the catalog item's user-facing variables.

Source: ServiceNow Product Documentation

"Form design

" Washington DC release.

In ServiceNow, the visibility and availability of configuration records, including Change Models, are primarily controlled by the 'Active' field. When a new Change Model is created, this flag must be set to 'True' for it to appear in selection lists, such as the one on the change landing page. This mechanism prevents incomplete or unapproved models from being used prematurely. Since the testers can view existing models, it indicates their permissions are sufficient, and the issue is specific to the state of the new model record itself.

A. An unpublished workflow would prevent a change request from progressing through its lifecycle after the model is selected, but it does not affect the model's visibility for selection.

B. The testers can already see the old change models, which confirms they have the necessary base roles (e.g., itil) to access and view change models in general.

C. While role-based restrictions can be configured, the 'Active' flag is a more fundamental and common reason for a newly created model not being visible.

1. ServiceNow Product Documentation - Create a change model: The official documentation for creating a change model lists the fields on the form. For the 'Active' field

the description explicitly states

"Select the check box to make the model available for use." This directly confirms that the model's availability is dependent on this setting. (ServiceNow Product Documentation

ITSM Change Management

"Create a change model"

Rome/San Diego/Tokyo/Utah/Vancouver releases).

2. ServiceNow Product Documentation - Change models: This document explains that change models define the process for a change. The system filters the list of available models based on their configuration

a key part of which is the 'Active' status. (ServiceNow Product Documentation

ITSM Change Management

"Change models"

Rome/San Diego/Tokyo/Utah/Vancouver releases).

The problemcoordinator role is responsible for managing the full lifecycle of a problem record, which includes key communication steps. The "Communicate workaround" and "Communicate fix" actions are integral to this management process. The problemadmin role has all the capabilities of the problemcoordinator in addition to administrative privileges for the Problem Management application. Therefore, both roles have the necessary permissions to perform these communication actions on a problem record.

A. itiladmin: This role is primarily for configuring ITSM applications, not for the day-to-day operational management of individual problem records.

C. problemtaskanalyst: This role is scoped to work on assigned problemtask records and does not have permissions to manage or perform major communications on the parent problem record.

1. ServiceNow Product Documentation - Roles in Problem Management:

The documentation explicitly defines the responsibilities for Problem Management roles. It states that the problemcoordinator [snproblemmanagement.problemcoordinator] "Can manage all problems and problem tasks." The problemadmin [snproblemmanagement.problemadmin] "Has access to all Problem Management features and capabilities

" which includes the coordinator's permissions. This confirms these two roles are responsible for managing the problem

including communications. The problemtaskanalyst is limited to tasks. (ServiceNow Product Documentation

Quebec Release

"Roles in Problem Management").

2. ServiceNow Product Documentation - Problem Management process flow:

The documented process flow for Problem Management shows that communicating a workaround is a key step in the "Diagnose" phase

and communicating a fix is part of the "Resolve and Close" phase. These actions are performed by the user managing the problem

which is the problemcoordinator or problemadmin. (ServiceNow Product Documentation

Utah Release

"Problem Management state model and process flows").

The "Assign to me" UI action is designed to set the assignedto field to the current user. When the assignmentgroup field is empty, the system must also populate it to ensure proper routing and metrics. If the agent clicking the action is a member of only one group, the system automatically populates the assignmentgroup field with that group. However, if the agent belongs to multiple groups, the system cannot logically infer the correct group context for the assignment. To resolve this ambiguity, it presents a dialog box prompting the agent to select the appropriate assignment group from a list of their memberships.

B. An error is not displayed. The system provides a user-friendly prompt to gather the necessary information to complete the action.

C. The Assignment group field is intended to be populated by this action; it will not remain empty if the user completes the prompt.

D. Standard ServiceNow functionality does not use a "primary group" concept for users. The system requires an explicit choice when multiple options exist.

1. ServiceNow Product Documentation - Incident Management: The process for self-assignment is detailed

specifying the system's behavior in different scenarios. The documentation states

"If you belong to more than one assignment group

a dialog box appears. Select the group that you want to assign the incident to and click OK."

Source: ServiceNow Product Documentation

"Assign an incident to yourself

" Washington DC release.

2. ServiceNow ITSM Implementation Courseware: Official training materials for the CIS-ITSM certification cover the core functionalities of Incident Management

including the behavior of standard UI actions like "Assign to me." These materials explain that the system prompts for a group selection when a user is a member of multiple groups to ensure the incident is correctly categorized.

Source: ServiceNow Training and Certification

ITSM Implementation — Participant Guide

Section: Incident Management Fundamentals.

The Requested Item [screqitem] table is the correct source for this report. Each time a user orders an item from the Service Catalog, a unique Requested Item (RITM) record is created. This record contains all the specific details of that order, including the catalog item ordered and the values selected for its associated variables, such as 'extra memory'. Therefore, to compare how many requests for the 'Computer' item included extra memory versus the base configuration, one must report on the screqitem table and group the results by the specific variable that captures the memory choice.

A. Build report on SC Task table, Group by Variables for Computer > Extra memory: The Catalog Task table (sctask) contains fulfillment tasks. Reporting here is unreliable as an item may have multiple tasks or none at all.

C. Build report on Task table, Group by Variables for Computer > Extra memory: The Task table (task) is a base table for all tasks. It is too generic and does not directly contain catalog variable information.

D. Build report on Request table, Group by Variables for Computer > Extra memory: The Request table (screquest) is a high-level container for one or more requested items and does not store item-specific variable data.

E. Build report on Catalog Item table, Group by Variables for Computer > Extra memory: The Catalog Item table (sccatitem) stores the definition of the item, not the transactional data of individual orders and their selected options.

1. ServiceNow Product Documentation

"Reporting on service catalog variables": This document explicitly states

"You can report on service catalog variables that are associated with a requested item." It guides users to select the Requested Item [screqitem] table as the data source when building such reports. (ServiceNow Product Documentation

ITSM

Service Catalog

Doc ID: KB0718148

Section: "Procedure").

2. ServiceNow Product Documentation

"Service Catalog data model": The official data model illustrates that the Requested Item [screqitem] table is the central record linking a Request (screquest) to a specific Catalog Item (sccatitem) and its associated Variables. This confirms it as the correct table for transactional reporting on ordered items and their options. (ServiceNow Product Documentation

ITSM

Service Catalog

Section: "Service Catalog data model").

3. ServiceNow Developer Documentation

"screqitem table": The API documentation for the screqitem table describes its purpose as managing "individual items in a request

" which includes the variables chosen for that specific item instance. (ServiceNow Developer Documentation

API Reference

Tables

screqitem).