Service Portfolio Management practice questions

Business Service Portfolio category mapping

Why it fails: Categories are for grouping within the portfolio, not CI mapping.

Service Offering Pricing model

Why it fails: Pricing models handle financial aspects, not infrastructure mapping.

Dynamic Service Offering Subscription

Why it fails: Subscriptions relate users or groups to service offerings, not infrastructure CIs.

Catalog Item user criteria

Why it fails: Catalog item user criteria control ordering in the Service Catalog, not portfolio administration visibility.

User Profile role assignment of 'sn_spm.portfolio_viewer' globally

Why it fails: Global role assignment grants view access to all portfolios, not specific ones.

CSDM Foundation Domain Separation rules

Why it fails: Domain separation is an enterprise-wide architecture, not the standard tool for portfolio-level visibility.

ast_contract

Why it fails: Contracts handle vendor agreements and renewals, not the direct cost allocation lines for offerings.

cmdb_ci_service_offering

Why it fails: This table stores the offering records themselves, not the granular expense or financial cost allocation lines.

sn_spm_service_portfolio_cost

Why it fails: This is a distractor; costs are managed through Financial Management (FSM) and CSDM expense lines.

Delete all downstream Application Service mappings

Why it fails: Deleting mappings breaks historical ticket references tied to those CIs.

Purge all historical incident records associated with the service

Why it fails: Purging historical data destroys audit trails and reporting capability.

Convert the service record into an Application Service CI

Why it fails: Conversion changes the architectural model, which does not address retirement and reporting integrity.

System Definition -> UI Policies

Why it fails: UI Policies dynamically set field behaviour on forms, so they cannot build the hierarchical service taxonomy that drives Service Portal browsing. It tempts administrators already working in form configuration, but UI Policies are for making fields mandatory, read-only or visible; the taxonomy lives under Service Portfolio Management.

CMDB Class Manager -> Relationship Rules

Why it fails: Relationship Rules define permitted CI-to-CI relationships in the CMDB, not the end-user-facing service taxonomy. It tempts because services are stored as CIs, but the taxonomy is configured in Service Portfolio Management, which controls portal categorisation rather than class relationship validation.

Service Level Management -> SLA Properties

Why it fails: SLA Properties hold Service Level Management settings such as schedules and timers, not the service hierarchy shown to portal users. It tempts because SLAs relate to services, yet the taxonomy is defined in Service Portfolio Management, not under Service Level Management.

Inside the CSDM Relationship builder as a dynamic CI link

Why it fails: CSDM links CIs; OLAs are tracked through the Service Level Management application.

Within the Catalog Item workflow definition

Why it fails: Workflows dictate request steps, not OLA compliance mapping.

Directly on the Service Portfolio record as child attachments

Why it fails: Portfolios do not track operational level agreements directly.

It exists independently outside of the Service Portfolio hierarchy

Why it fails: All business-facing services and offerings should be organized under the portfolio.

It acts as the parent container for the Service Portfolio

Why it fails: The portfolio is always the parent container.

It replaces the Business Service record entirely

Why it fails: Catalog items do not replace business services.

sn_sec_incident_analyst

Why it fails: This role is for Security Incident Response, not SPM.

itil

Why it fails: The ITIL role is for general incident, problem, and change processing, not specific portfolio administration.

sn_vul.vulnerability_admin

Why it fails: This role pertains to Vulnerability Response.

Hardware Asset Tag Registry

Why it fails: Asset tag registries belong to Asset Management, not the core CSDM conceptual domains.

Discovery Schedule Configuration

Why it fails: Discovery schedules belong to ITOM Discovery, not CSDM core entities.

Wi-Fi signal strength decibel levels

Why it fails: Signal strength is a network monitoring metric, not an SPM dashboard attribute.

Hard drive RPM and spindle speed

Why it fails: Hardware specifications belong to asset management / CMDB, not SPM health dashboards.

Create a new Service Offering and set its 'Service' field to the Business Service, then manually create a catalog item and set its 'Offering' field.

Why it fails: While creating a Service Offering and catalog item is part of the process, the 'Used by Service Catalog' flag on the Business Service must also be enabled. Without that flag, the offering will not be properly recognized as catalog-available. This option misses the required flag and is therefore incomplete.

Add the Business Service directly to the Service Catalog as a category and create catalog items under it.

Why it fails: Categories in the Service Catalog are used to organize catalog items, not to represent Business Services. Adding a Business Service as a category does not create the necessary offering or item relationship. This approach fails because catalog items must be linked to Service Offerings to be requestable.

Publish the Business Service by setting its 'Lifecycle Stage' to 'Published' and enable the 'Requestable' checkbox on the service record.

Why it fails: Lifecycle stages track the state of a service but do not control catalog availability. The 'Requestable' checkbox does not exist on Business Service records; requestability is managed through Service Offerings and catalog items. This option confuses lifecycle with catalog exposure and is incorrect.

Business Service

Why it fails: A Business Service represents a service provided to business customers, but it is not the top-level grouping in CSDM. It sits under a Service Portfolio and may have multiple offerings. Using it as the top grouping would ignore the portfolio hierarchy defined by CSDM.

Application Service

Why it fails: An Application Service represents the technical functionality provided by applications, not a business-facing grouping. It is part of the technical service hierarchy and supports Business Services. It is not used as a top-level grouping for service portfolios in CSDM.

Service Offering

Why it fails: A Service Offering is a specific commitment or variant of a Business Service, such as different service levels or pricing. It is not the top-level grouping; it resides under a Business Service. Using it as the top grouping would invert the CSDM hierarchy and cause misalignment.

Create a cost model for each offering and associate it with the parent business service

Why it fails: Creating a cost model per offering is granular but does not automatically roll up to the business service unless the business service is configured to aggregate offering costs. The requirement is to track TCO at the business service level, so the cost model should be applied at the appropriate level. This approach could lead to duplicate or missing costs if not properly linked, and it does not guarantee accurate roll-ups across all offerings.

Use the Financial Management application to create expense lines for each cost source and link them to the portfolio

Why it fails: Financial Management expense lines are used for budgeting and accounting, not for service cost roll-ups in SPM. Linking expenses directly to the portfolio skips the business service level and does not provide the granularity needed to track TCO per service. This method would not automatically aggregate costs from offerings and could misrepresent the true cost of the business service.

Configure a scheduled job that imports cost data from external systems into the Service Offering table

Why it fails: Importing cost data into the Service Offering table via a scheduled job is a manual and error-prone approach. It does not leverage the built-in cost model functionality of SPM, which is designed to calculate and roll up costs automatically. This method would require custom scripting and maintenance, and it would not provide the integrated TCO tracking that the business service cost model offers.

Asset Management Depreciation Schedules

Why it fails: Depreciation schedules are used for fixed assets and do not apply to service offerings that include cloud and labor costs. They are not designed to roll up operational costs. This option is incorrect because it addresses a different financial process and does not meet the requirement.

Service Portfolio Financial Baselines

Why it fails: Financial Baselines are used for budgeting and forecasting at the portfolio level, not for detailed cost roll-up of a single Service Offering. They do not capture the specific costs of cloud hosting, support, and labor. This option is incorrect because it lacks the required granularity.

Financial Management Cost Centers

Why it fails: Cost Centers are used to allocate expenses to departments, not to roll up costs for a specific Service Offering. They do not provide the granular linkage to offerings and their components. This option fails because it does not aggregate costs at the offering level.

Ensure all associated service offerings are also moved to 'Retired' or 'Decommissioned'

Why it fails: While it is good practice to retire offerings when retiring a business service, ServiceNow does not enforce that all offerings must be retired first. The system allows a business service to be moved to 'Retired' even if offerings are still active, although this may leave orphaned offerings. The requirement is to follow the lifecycle transition rules, which do not mandate prior retirement of offerings. Therefore, this is not a mandatory step.

Remove the service from all service portfolios

Why it fails: A service can be retired while still associated with a portfolio. The portfolio association is used for reporting and does not block retirement. In fact, keeping the service in the portfolio with a 'Retired' stage provides a historical view. The system does not require removal from the portfolio before retirement, so this is not a mandatory step.

Delete all associated SLAs and service level agreements

Why it fails: Deleting SLAs is not a prerequisite for retiring a service. SLAs are typically deactivated or left as historical records when a service is retired. The system does not require their deletion, and deleting them could remove valuable historical data. The lifecycle transition does not check for the absence of SLAs, so this is not a required step.

Assign a unique Service Category to each portfolio to enforce hierarchy

Why it fails: Service Categories are used for classification and reporting, not for enforcing portfolio hierarchy. While categories can help organize services, they do not define the portfolio structure. The hierarchy is defined by the portfolio-to-business-service association. Assigning categories does not create the required parent-child relationships and would not establish the portfolio hierarchy as needed.

Define a parent-child relationship between Service Portfolios and Business Services using the 'Parent' field on the portfolio

Why it fails: The parent-child relationship between portfolios and business services is not defined by a 'Parent' field on the portfolio. Instead, the business service has a portfolio reference field. Portfolios can have parent portfolios for nesting, but business services are linked to portfolios via the portfolio field on the business service. Using a parent field on the portfolio would not correctly associate business services.

Create a Service Offering for each business service to represent the portfolio

Why it fails: Service Offerings are not used to represent portfolios. Offerings are child records of business services that define variants with specific SLAs and pricing. Using offerings to represent portfolios would invert the hierarchy and cause confusion. The portfolio is a separate entity that contains business services, not offerings. Therefore, this action is incorrect for establishing the portfolio hierarchy.

Configure the Service Offering to inherit SLAs from the Business Service and override per department.

Why it fails: While inheritance from Business Service is possible, overriding per department at the offering level is not a standard feature. SLAs are usually attached directly to offerings or defined with conditions. This method is not supported out-of-the-box for per-department overrides on a single offering.

Create a single Service Offering and use the 'Offering Type' field to denote different service levels.

Why it fails: The 'Offering Type' field is used to categorize the nature of the offering (e.g., Internal, External), not to represent different service levels. Using it for service levels would be a misconfiguration and would not provide the necessary SLA differentiation.

Use the 'Service Level' field on the Service Offering to select multiple values.

Why it fails: The 'Service Level' field on a Service Offering is typically a single reference or choice field, not designed for multiple values. It cannot hold multiple service levels simultaneously. This approach would not support the requirement for multiple service levels per offering.

The business service cost is calculated by averaging the cost models of its offerings

Why it fails: Averaging offering costs is not how SPM calculates total cost. The correct method is summation, not averaging. Averaging would understate or overstate the total cost depending on the number of offerings and their individual costs. The system sums the costs from all offerings and adds them to the business service's direct costs. Therefore, averaging is incorrect and would produce misleading financial data.

The business service cost is only the sum of its own cost model; offering costs are reported separately

Why it fails: This is incorrect because SPM is designed to roll up offering costs into the parent business service. If offering costs were excluded, the business service cost would not reflect the true total cost of ownership. The system aggregates costs from child offerings to provide a consolidated view. Reporting offering costs separately would require manual consolidation and would not give the service owner the total cost they need.

The business service cost is the higher of its own cost model or the sum of offering cost models

Why it fails: ServiceNow does not use a 'higher of' logic for cost roll-ups. The total cost is the sum of the business service's direct costs and all offering costs. Using the higher value would ignore either the direct costs or the offering costs, leading to an inaccurate total. The system is designed to aggregate all costs to provide a true total cost of ownership, so this approach is incorrect.

Retroactive Start calculation override

Why it fails: Retroactive Start recalculates an SLA's start point when a record is created late, shifting the timeline backwards; it does not pause the clock. Pausing while a customer supplies information, with elapsed pause time excluded, is handled by the Pause condition and its related pause duration fields.

SLA Workflow timer extension

Why it fails: Workflow timer extension adjusts a running timer's duration; it does not evaluate a pause condition or exclude paused time from the SLA calculation. It is tempting because workflow timers underpin SLA processing, and extending them is a genuine technique when an SLA's total duration must be lengthened.

Business Rule intercepting task state changes

Why it fails: A Business Rule fires on task state changes but does not define pause conditions or exclude elapsed pause time from SLA duration. It is tempting because Business Rules are the general-purpose scripting tool for task automation, and they can legitimately drive state transitions that an SLA then reacts to.

Business Service Definition

Why it fails: Business Service Definitions describe business-facing services and their SLAs, not the priced, committed service level within a service portfolio. In ServiceNow, a Service Offering is the distinct level carrying pricing, delivery commitments and SLAs for a standard service, so this term names the wrong construct.

Service Level Commitment (SLC)

Why it fails: An SLC is a commitment made to a specific customer or internal group, not the distinct service level that carries pricing and delivery terms. It is tempting because SLCs do define commitments, but they sit beneath the service level rather than constituting it.

Service Portfolio

Why it fails: The Service Portfolio is the complete set of services a provider manages across the lifecycle, not a single service's pricing and commitment level. It is tempting because the portfolio does contain services, but it is the container, not the defined level itself.