Usage of "Approval Group," "Support Group," and "Group Change" fields in cmdb_ci_service

[Yuya Toda]

I hope you're all doing well. I have a question regarding the cmdb_ci_service table in ServiceNow. I've been exploring the fields "Approval Group," "Support Group," and "Group Change" within this table, and I'm curious to understand their specific purposes and use cases.

[SANDEEP28]

@Yuya Toda Below is the explanation.

Approval Group : Its kind of an approval group of configuration item. Lets say if there an change request raised for that CI then it will request approval from members within that approval group present in that CI. 

Support Group: For tasks, you have an assignment group. That is the group that is responsible for resolving the task. Then on e.g. CI's you can have a field Support group. That is just to know who does the support on this CI. In other words, if there is an incident on this CI, put this group as assignment group. This is one of the reason customers have functionality that when you fills in a CI on an incident, it takes the value of that CI's Support group and put that in the assignment group on the incident (task).

Group Change:  Refer below community post to understand purpose of Group change field.

https://www.servicenow.com/community/cmdb-forum/why-did-cmdb-ci-assignment-group-field-got-relabeled...

If I could help you with your Query then, please hit the Thumb Icon and mark as Correct !! 

[CMDB Whisperer · Accepted solution]

Support Group is the group that is responsible for supporting incident resolution.

Change Group is the group that is responsible for implementing changes.

Approval Group is the group that is responsible for approving changes (and possibly requests or other activities as well)

Note that you may have multiple groups that help to support incidents, and even multiple groups responsible for implementing changes on a given CI.  These are here to determine who is the primary responsible group.  Individual incidents, changes, requests may still be assigned to other groups as needed.  It is NOT the job of CIs to define these different possibilities, escalation paths, etc.  So be careful of the temptation to define additional custom Group fields to specify secondary/alternate groups, as this is likely to be difficult to maintain and will likely add unnecessary confusion to your processes rather than help to define responsibilities as intended.

[Yuya Toda]

@SANDEEP28 @CMDB Whisperer 

Thank you all for your responses. I appreciate your insights into the specific use cases for each item. Are there any instances where these items are used to facilitate automated processes?

[CMDB Whisperer]

One automated process is the synchronization of these fields themselves.  When these values are supplied on a Technical Service Offering, and that Technical Service Offering is associated with a Dynamic CI Group, the values of these fields cascade down to the individual CIs within the Dynamic CI Group.  For example, if I have a TSO called "Windows Server Management" which depends on a Dynamic CI Group called "All Windows Servers", and the TSO Support Group called "Windows Server Team", then all of the individual Windows Servers will by synchronized with the TSO so that they also have a Support Group of "Windows Server Team".

I'm not sure, but there may be a default function somewhere that can result in Incidents automatically being assigned to the Support Group of the primary CI.  If it's not automated out-of-box, it's certainly a common configuration or end result of the process.  

As far as I am aware, there is no automated functionality out-of-box associated with Change Group or Approval Group on a CI.  At least there wasn't the last time I looked.

These group fields only really started to get focused attention after CSDM 3.0 was introduced.  So it's possible that some out-of-box processes have continued to leverage these fields.  And if not, then it's very likely they will be leveraged more out-of-box in the future.  That's the way things tend to evolve with CSDM.