Pass the ServiceNow CIS-Service Management CIS-ITSM Questions and answers with CertsForce

Once any class is set as a principal class, the principal class filter is automatically applied to the CI field on change, incident and problem records. This means that only CI's within a principal class can be selected on the CI field. If there are no CI Classes marked as Principal Class, then all CIs on all forms will be selectable on the CI field.

Now Create is ServiceNow's official implementation methodology. For a Business Analyst preparing for a Service Catalog workshop, the two most critical documents are:

Workshop Preparation Guide (A): This asset outlines the objectives, agenda, and necessary stakeholders for the workshop. It helps the analyst understand the flow of the session and the specific decisions (like catalog structure and categories) that need to be captured.

Process Guide (B): This provides the deep-dive technical and functional baseline for how Service Catalog and Request Management should work. Reviewing this ensures the analyst understands standard terminology (e.g., RITMs, Tasks, Stage vs. State) before they attempt to document custom requirements.

In ServiceNow IT Service Management (ITSM), the Service Catalog is a central repository of goods and services available to users. While a catalog is organized by Categories (A), categories themselves are containers, not items. Execution Plans (C) are legacy mechanisms used to define processes, and Requested Items (D) are the specific instances of an order after it has been placed (stored in the sc_req_item table).

A Record Producer (B) is a specific type of catalog item that allows users to create task-based records, such as Incidents or Change Requests, directly from the Service Catalog. Unlike standard catalog items that result in a Request (sc_request), a Record Producer uses a simplified interface to gather information and map it to fields on a target table, making it a fundamental component of the Service Catalog ecosystem.

In Change Management, specifically when using the Change Model framework (introduced in the Rome release to provide more flexibility than legacy workflows), state transitions are governed by specific conditions. For a Change Request to move from the Authorized state (where it has been vetted by the CAB or technical leads) to the Scheduled state (where it is ready for implementation), the system must verify that the necessary approvals have been granted. Therefore, the "Requires" field is set to Task is Approved to ensure that the transition only occurs once the approval engine returns a positive result.