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?

How are you managing changes to the CMDB