How are you managing/validating the Ownership information of CIs?

[Suggy]

Today we are using OWNED BY, MANAGED BY fields for Server and other CIs. 

But the problem we are seeing is, how to maintain it as users would leave the org, users might change the role, change the department etc and those fields would be outdated.

So looking for a process to 'Validate that data regularly' and 'How to update' when there is a change in the value.

[Brian Bouchard]

We have a flow that is triggered when someone is deactivated in ServiceNow that looks at all the things that person may have requested/been assigned, manaer of, owner of, etc.. and acts on them accordingly at the time the person is deactivated.  For Owned By and Managed by, we automatically set those values to the manager of the person that was previously listed and send that person an email with the list of things that were reassigned to them and instructions on how to update it to someone else if needed.  This way, when any of our automated processes run for data certification/validation, there is always an active person who is being assigned those tasks.

I'm sure there are other ways to handle it (and maybe more efficient) but works well in picking up both planned and unplanned separations from the company.

[Mark Manders]

The best way is to try and use groups. Because with inactivation it is easy: you can just reassign to another team, to the manager, or create reports/dashboards for it, so it is visual.

But when users get a different role, you will need some logic in there as well... If you are managing this by group membership, you could decide to send the person and his old manager a list of all the assigned to's ownerships and jobs running in his name, so they can go through it and decide what needs to be done with it.

[Suggy]

@Mark Manders so you are only managing the 'Groups' is it? Then you are not managing Owned by (who tracks the financials), Supported by (used ex in Incident management) etc?

[Mark Manders]

Owned by is also managed for some CI's, but often set to the manager of the owner group. This way, if it is concerning the manager, you can notify the entire group that something should be checked. And logic can easily applied that if the manager of a group changes, it should also update on all the records. 

But, as mentioned before, when people get different roles within a company, often the administration within ServiceNow is forgotten. That is my experience. So after months or even years, someone is checking and says 'Why is John owning these servers? He is head of one of the HR teams now, right?" and no-one ever bothered about it (and John was just ignoring the notifications about the servers, because it wasn't his job anymore). Using groups makes that the responsibility is shared (and can be validated).