Why are Service Committment related SLAs triggered based on cmdb_ci instead of service_offering task field?

[Niclas]

I was just reviewing Vendor Manager Workspace, which has a vendor specific SLA reporting based on Service Offerings.

By installing this plugin,SLA Definition is extended as followed:

• Field "Vendor"
• Checkbox "Service Commitment"
• Related List "Service Comittments", which I assume need to be linked to Service Offerings.

I set up a SLA Definition where Service Comittment is true and noticed these SAs are only triggered if the Task (e.g. the Incident) is linked to a Configuration Item [cmdb_ci] of Class Service Offering. This works as documented in Madrid. Also a quick review of the Business Rule shows, that the [cmdb_ci] field is used.

I'm wondering here: Why are the service offering related SLAs triggered based on [cmdb_ci] instead of [service_offering] field? Isn't the right place to store the Service Offering on the Service Offering field? And use Configuration Item to store the physical item? (e.g. Service Offering = Laptop Support Germany, Configuration Item = Laptop HP 850 12345

Also, I need to be honest, it's very difficult to understand how to set up the Relation of SLAs and Service Offerings to support Vendor Manager Workspace. The documentation linked above is from Madrid and I don't see a more up to date documentation. 

. 

[Stig Brandt]

Have worked with this issue for the past 7-8 years, never really got a logic explanation from servicenow. Have change the code to use the service offering field in a number of implementations, to trigger the sla. This raise though another issue, if two service offerings is involved, technical and business, do we then need to tickets or would we raise one ticket, with two so sla’s and what about the real ci affected. Cheers

[Niclas · Accepted solution]

Hi Stig, just learned from my colleagues that there is a property! (at least in Orlando). Property name is com.snc.service.offering.field and you can change value from cmdb_ci to service_offering!