Definitions or recommendations for using CI user and group fields

[Jon Miller1]

We're in the process of reimplementing our CMDB after 5+ years of an ungoverned free-for-all! I need some help in making sure we make good decisions now that will put us in a good place for the future.

Can anybody provide any thoughts, recommendations, definitions, lessons-learnt, etc. on the correct usage of the following CI fields: Approval group, Assigned to, Change Group, Managed By Group, Managed by, Owned by, Support group and Supported by? I'm not getting a clear answer from our implementation partner and haven't found any ServiceNow documentation on this topic.

I'm fairly clear on Change Group (used to assign Change Requests) and Support Group (used to assign Incidents). But I'm getting conflicting information about whether Approval Group or Managed By Group is used by the CMDB Data Manager and, if it uses one of them, what is the other one for?

I understand Assigned To when it comes to personal devices (PCs, laptops, etc.) but are folks using it for servers? I'm thinking of using it for who requests a server build and who the server is "delivered to" for deployment after it is built by the server team. Is that appropriate?

I'm thinking of using "Owned By" to define the "data owner" of the CI in the CMDB (i.e. the person responsible for data quality) rather than the "owner" of the physical asset. The idea that somebody "owns" a server is troublesome (I'm OK with a server being assigned to someone or being managed by someone but not being "owned"). Is that a good idea?

That leaves Managed By. Is that intended to be a single-point-of-contact (SPOC) within the Managed By Group? Or are they unrelated and serve different purposes? Is Managed By associated with CMDB Data Manager or Technical Services? That's not real clear to me yet.

Thanks in advance,

Jon

[Jon Miller1]

Thanks Mary. This is very helpful. Wouldn't it make more sense to have the out-of-the-box forms align to the CSDM and for legacy customers to modify them if needed (rather than the other way around)? IMO, ServiceNow have put a barrier to adopting the CSDM by the standard forms not being aligned to it.

I notice you include the Approval Group. Is that still required or is that legacy also? From what I'm seeing in the system, it has been replaced by Managed By Group (for approving CMDB Data Manager tasks) and Change Group (for Change Request assignment and approval). That theory would be supported by Approval Group not being referenced by the CSDM Data Sync, even though Approval Group is still on the Technical Service and Technical Service Offering forms. Or am I missing a use-case for Approval Group? Apologies if this is answered in the documentation you provided. I haven't finished reading through it all yet.

A second, similar question... the use-cases for Owned By v Assigned To on, for example, a Windows Server CI? I notice Assigned To is on the standard Windows Server form (not Owned By) but Owned By is on the Technical Service and Technical Service Offering forms. Is that actually the answer to the question? Is the Owned By the owner of the service but Assigned To is who the CI (server in this case) is assigned to? That does make logical sense (it answers question about what it means to "own" a server) but I've not seen it documented anywhere (though, like I say, I haven't got through all the latest documentation yet).

Jon

[Dominic5]

FYI, "Managed by" is shown in Digital Portfolio Management (.../now/dpm/enterprise-portfolios/sub/service-details/cmdb_ci_service_business) in the header info out of the box, so presumably isn't that legacy (in Utah at least).

On a more general note, I'd argue that having fields for named individuals is important for "ownership" type roles (accountability), whereas groups are great for operational responsibility.

[Mary Vanatta1]

Yes it seems as if it would make more sense to have the OOB forms align, however, upon an upgrade to a newer version this could "break" the forms for legacy customers. I will suggest to inbound product manager this be considered for new customers with new implementations. 

The approval group is still used in Change Management to approve the changes.  Approvals can be added automatically. This is usually based on the CIs that have been related to the Change​. In short, this is configurable. This is configured in the Change Approval Policies. On a Normal change OOB, the CAB Approval  group is set in the "Change Policy> Approval Definitions" (navigation)  Here you can set the group you want to be the Approvers group,  the CI record can provide the this information. 

• Automated approval or rejections can be achieved using approval policies.​
• Example low risk Changes, allow integration for DevOps.
•  If no approval groups are discovered automatically the Change will move through that state as if it has been approved therefore it is necessary to ensure that if no approvers found in the approval policies, to use a ‘catch-all’ Change policy.
• It is recommended to add the Group Approval> Parent related list to show Approval Groups. Display the New button on the Group Approvals related list if the customer would like the opportunity to manually add approval groups. Relabel the Approval user column to Approver on the Group Approvals related list 
  ​Change Management Workshop (slides 65 and 66 notes section for more info)
  This makes a  great use case for using Dynamic CI Groups (technical service offering)  Example:  you have 2 datacenters one in Japan and one US.  Japan has a separate Change Group and Approval group than the US ​for Windows Servers based on location. You can create a 2 CMDB Groups using a encoded query to filter the Windows servers based on location. Then add the CMDB Group to a Technical Service Offering based on location.  Here you can add the different Approval and Change groups based on location. 
  
  In some organizations, smaller and less mature processes, the Change Group and Support group maybe the SAME group.  (ex;  Windows Administrators or the Server Admins)

[Jon Miller1]

Sorry if I'm being dense, @Mary Vanatta1, but I'm not seeing that in the system. I'm sure you're right that the Approval Group could be configured to be used in Change. But what I'm seeing in my Tokyo PDI is that (a) the Change Policy for a Normal Change says that the Assignment Group on the Change record is what drives the approval, (b) the Business Rule for populating the Assignment Group gets it from assignment_group field on the CI, and (c) the label of the CI assignment_group field is Change Group (it's the change_control CI field that's labelled "Approval Group"). That is, CI Change Group (assignment_group) > Change record's Assigned Group > Change approval. I don't see any reference under Change to the Approval Group (change_control). Am I missing it somewhere?

Jon

[Mary Vanatta1]

The Approval group on the Approval Definitions screenshot:

The Assess Technical Approvals uses "Assignment Group" this used to send the change to be approved by the assignment group, often before the CAB Approval.   These can all be configured in the platform, formerly using the Workflow Editor and now with Flow Designer.  
Requirements would need to be gathered on the flow your organization needs.  The Approval Group on the CI form can be populated and used to populate the data per the workflow.