- Different Tables, Different Choice Lists
Even though both fields may be named "business_criticality", they are defined independently on different tables:
Table | Field | Source |
cmdb_ci_business_app (Business Application) | business_criticality | Own choice list (customizable) |
service_offering | business_criticality | Own choice list (possibly inherited from a dictionary override or different enum list) |
So, unless they are explicitly linked via a dictionary override or reused reference, each one can have different values.
- They Serve Different Purposes
- Business Application criticality is often tied to application rationalization or IT Risk, defining how important a software application is to business operations.
- Service Offering criticality is used more from a Service Portfolio/Delivery lens — how important is this offering (feature or part of a service) to business customers.
Thus, each has its own context, and ServiceNow allows them to be independently configurable.
- How to Make Them Consistent (If You Want To)
If your organization wants consistency, you can do one of the following:
- Option A: Use a dictionary override to make the Service Offering’s field reuse the Business Application choice list.
- Option B: Synchronize both choice lists manually (update them via system definition > Choice Lists).
- Option C: Reference a shared table or picklist for business criticality values across your CMDB.
How to Check the Differences
- Go to System Definition > Dictionary
- Search for the business_criticality field
- Compare the entries for:
- cmdb_ci_business_app.business_criticality
- service_offering.business_criticality
You’ll likely see they have separate choice lists.
