How are you managing changes to the CMDB

Sean_Terry

Are you restricting access somehow? Are you triggering notifications so a team can monitor changes to the CMDB?

For our area it would be good if the CMDB had the option to restrict edits or trigger notifications or you could have a RO to request changes and if approved, a runbook or PowerShell can overwrite or amend changes.

Adam_Dzyacky

When you say "managing changes to the CMDB" I assume you're referring to controlling/monitoring changes to the Configuration Item side of the house as opposed to Work Items? or everything? Either way both (in my opinion) should start at the RBAC/permissions level. Give people exactly what they access to. Then move onto what to do about changes to said items.

From a Work Item perspective: Apart from controlling Queue permissions. There is an infinite amount of workflow possibilities here. The simple ones you can configure in the console, the more complex ones Orchestrator, and the most custom of workflows - PowerShell based Management Packs. Such workflow examples include:

• If you assigned to someone who is Out of Office, assign back to the previous Assigned To
• If the Created By user in a CR, votes for someone else within that Change, a runbook should either exist inline (or externally always listening) that sanity checks to make sure someone isn't approving their own requests. If they are, raise and relate an Incident

From a Configuration Item perspective: So much of the CI side of things should hopefully getting driven by Active Directory, SCOM, SCCM, SCO, VMM, or Cireson Asset Import connectors. Which even if your permissions are lacking in this area, should someone change something, it's just overwritten the next day by the connectors. That said, let's say it isn't and you want to monitor for changes made against CIs in the middle of the day/changes made by not the connector accounts. I would tend to default on a PowerShell based MP here for something such as:

• If the Consumable count drops due to manual intervention (e.g. not a service account performing the change), reset the count, create an SR/CR with associated runbook that takes the new count as a parameter. Either way, this SR/CR requires approval before actually doing the change

Not sure if this answers your question?