Use configuration context in incidents and changes
Configuration Management enabled, CSM Full and relevant staff permissions. CI and relationship writes require administrator rights; application permissions differ.
Configuration data adds operational context to service work. Different consumers resolve routing, maintenance and availability differently; there is no universal “most specific wins” rule for every policy.
Before you start
Maintain a valid Service/Offering route before relying on CI overrides. Confirm the relevant policy switches, technical permissions and environment. An Incident can be handled without a Primary CI.
Steps
- Select the correct Service and Offering on the Incident. In CSM Full, staff may add the Primary CI and additional affected CIs.
- Review assignment precedence: an explicit enabled Primary-CI support override; otherwise an explicit enabled parent Instance override found through one relationship hop; otherwise the Offering's assigned team.
- Inspect the dependency map and potentially impacted Instances/Offerings. Confirm actual effect and maintain findings in the Incident.
- For a Change, identify relevant Instances/CIs and shared resources. Assess other affected service commitments, rather than only the Service that first raised the work.
- Check every applicable REQUIRED maintenance window and all applicable blackout restrictions. Emergency exceptions require their documented conditions and justification.
- Use the Change's own review/authorization process. After implementation, update changed hosting, dependencies, status and environment facts.
Compare policy meanings
Routing uses configured override precedence and a one-hop Instance lookup. Dependency impact can traverse multiple hops, up to the documented ten-hop cap. Required maintenance windows combine as an intersection. Blackout restrictions accumulate. Documented availability-policy configuration uses Offering, then Service, then tenant default precedence.
A Request linked to a Change does not prove that Change is approved or complete. A planned maintenance window does not automatically create an Outage. Each process needs its own evidence.
Expected result
Technical context improves assignment and planning while preserving support commitments, approvals and scheduling responsibilities.
Important behaviour
A support-team field alone does not establish that its override is enabled. A graph connection does not automatically reassign incidents. Model ownership and AgentHub roles do not grant unrestricted configuration administration.
