How to auto-populate a Technical Service from a related Dynamic CI Group

[Bob Mullineaux]

I want to auto-populate a Technical Service or Technical Service Offering on the Impacted Services tab on the Incident record based upon a CI that is a member of a Dynamic CI Group.  I have a Contains Relationship from the Service Offering to the Dynamic CI Group.  The Parent of the Technical Service Offering is a Technical Service.

The Dynamic Group is a list of IP Routers named "Wide Area Network Devices".   In the screen shot, I have a Technical Service Offering "Wide Area Network - Service Offering", with the Parent Technical Service "Wide Area Network Service Availability".   My need is to have the Technical Service auto-populate in the Impacted Services Tab when the Refresh Impacted Services UI Action is executed.   However, what is happening is the Dynamic Group gets populated as shown in the Incident form vs the Technical Service aka Impacted Service.

Is there a way (without custom coding) to get the Technical Service to populate based upon a CI that is a member of the Dynamic CI Group.

[EricDohr]

Really good approach with the adoption of Dynamic CI Groups.   

• One Technical Service can have many offerings.  For example, WAN could be your Technical Service and you have offerings such as WAN – Chicago, WAN – Milwaukee, etc.
• Each offering can have a CI relationship to a Dynamic CI Group.  For example, WAN – Milwaukee includes all routers
  • CI Class = Routers
  • Status = Installed
  • Location = Milwaukee
• Dynamic CI Group looks to a CMDB Group WAN – Milwaukee
• The CMDB Group looks at a CMDB Query where you have
• BTW, you could also use a CI Relationship of Offering to Dynamic CI Group of Manages:Managed By to pass on Group information through a scheduled job.  This way when a Router is discovered and meets the CMDB Query, you do not have to maintain the group information manually
• If you have not used the CMDB Query Builder yet, this is an excellent tool that allows you to set a base query and duplicate records / just adjusting location for each offering

So in an incident, if a router went down or you had ITOM alerting you, you would have

• CI = Router name (especially if you have ITOM this is huge)

You then could populate two fields

• Service-  WAN 
• Offering – WAN – Milwaukee 

If you have adopted Service Portfolio Management, this allows you to start seeing KPIs (depending on KPI group) breaking down at the Offering, Service, Node, or Portfolio level within Digital Portfolio Management Workspace.  This is a great way to aggregate KPIs and consume information from a Service Owner viewpoint.

You are correct in your bottom paragraph that Commitments are associated with Offerings.

• Services [cmdb_ci_services_business/cmdb_ci_services_technical] have one or many Service Offerings [service_offering]
• Offerings can have Commitments [service_commitment], including Availability (Defined based on schedule, timezone, percentage and precision). 
• There is an out of box related list on the Service Offering and Commitment tables called Service Commitments [service_offering_commitment]
• You can have shared commitments like 99.97% with a schedule of 24x7 that multiple offerings can be related to
• Commitments can have SLA Definitions [contract_sl] where you can define type (OLA, SLA, UC), target, duration, etc.
• Once you have a related record between the Offering and Commitments, behind the scenes the platform will build out records
• When there is an Outage [cmdb_ci_outage], you will make sure offerings are included on that record via Affected CIs [cmdb_outage_ci_mtom]
• When there is an outage record (Let’s say as part of Major Incident Management) based on the outage beginning and end time, you derive the outage time.  If it is within the commitment schedule, you can then see if the SLA was met (Daily, weekly, monthly, last X months, etc.)
• You will see the results of Service Commitment on SAL Results [service_sla_result]

Offerings can be based on location, support tier, and more.  Based on WAN, I most commonly see this based on geography, but I understand there are other options.  For Application Services, I have seen it based on Environment, Environment – Location, and a few other approaches.  Now Create CSDM Workshop has some great ideas on defining services and offering names.

A Business Application can be made up of multiple Application Services that could have different offerings and commitments such as App Support – Gold (Tier based).  Your production environment would have a higher commitment than your Sandbox most likely.