The exception that outlived the migration
Last spring I sat in a review of a Dynamics 365 production environment and asked for the list of users holding the System Administrator security role in Dataverse. There were nineteen. Four belonged to people who had left the company. Two were consultants whose engagement had ended the previous autumn. One was an integration account that had been given full rights during a data migration because a lookup would not resolve, and nobody had touched it since. Not one of the nineteen had a ticket, a date, or a name attached to it.
Every one of those grants was probably the right call on the day it was made. Migrations need broad rights for a weekend. A consultant building the first release needs to see everything. The mistake is never the exception itself. The mistake is that an exception granted on a Friday afternoon becomes permanent by default, because nothing in the platform or the process asks the question again. The pattern I push in every architecture review is short. An access exception is a piece of owned work. It has an owner, an end date, and a small record, and it gets reviewed before it expires rather than after an auditor finds it.
Exceptions are legitimate, and that is the problem
Standard role models are written for the ordinary week, and the hard week is when people need access. A go-live weekend for a Power Apps solution. An incident at two in the morning where the person on call needs to read a table their role does not cover. In ServiceNow it is the developer who needs the admin role to run a release because the update set touches something the delegated developer role cannot reach. In Dataverse it is the maker whose form would not save until someone added a privilege, and the fastest fix was a copy of System Administrator under a different name.
I do not argue against any of these in the meeting. Arguing usually pushes the exception underground, into a shared account or a colleague's open session. What I argue for is that the grant gets recorded the moment it is made, even at two in the morning. The guide to the first thirty minutes of a platform incident makes the same point about actions taken under pressure. Write down what you did while you still remember why.
An owner is one person who will be asked about it
The word owner needs to be precise. The owner is not the person who received the access. The requester wants the access and has every reason to keep it. The owner is the person who approved it and who will answer when someone asks, six months on, why the integration account still has full rights. That has to be a named individual. A team mailbox does not answer questions.
In practice the owner is usually the environment owner in Power Platform or the application owner for the ServiceNow instance, and in a healthy setup those are the same people who appear on the catalog entry the service desk reads. What I say in the review is this. If you cannot name the person who will be asked about this grant, you have quietly changed the role model rather than granted an exception. Either name someone or change the role model properly and put it through release.
Expiry is a date in a field, not an intention
Every exception I have seen extended indefinitely started life as temporary. The word temporary does nothing on its own. What works is a date in a field that something will act on. In ServiceNow ITSM the natural home is a request item or a standard change with a due date, an assignment to the owner, and a task that opens a week before the date. Some teams keep a small custom table with the same fields, which is fine as long as the owner actually opens the report over it.
On the Dataverse side the record can be the same ServiceNow item, and I prefer that it is, because the review then happens in the tool the owner already lives in. Where a team wants automation, a scheduled Power Automate flow that reads expiring exceptions, checks whether the role assignment still exists, and either removes it or raises the review task is a few hours of work. For environments that carry their own roles, the environment strategy should say who can grant System Administrator in production at all. That list should be short enough to read aloud.
The review before expiry has three possible outcomes and only three. Remove the access because the reason has gone. Extend it with a new date and the same owner, and record why. Or convert it, which means the exception has revealed a gap in the standard role model and the right move is a proper role that goes through release. The third outcome is the useful one. It is how the role model improves.
Keep the evidence small enough to review in a minute
The other way this pattern fails is that the record becomes a dumping ground. A reviewer opens the request and finds the full export the requester needed to see, a screenshot of a customer record, or the entire email thread. Nobody reviews that. Worse, the exception record now holds a copy of the data the exception was meant to control, and it sits in a ServiceNow table with far broader read rights than the Dataverse table it came from.
The reviewer needs four things, and each fits on one line. The source reference, which is the incident number, the project code, or the migration run identifier that caused the request. The purpose, in one sentence that a person outside the team would understand. The requested change, stated as the exact role, the exact environment or instance, and the exact user or account. And the date it ends. Use identifiers rather than copies. If the purpose was to correct records for account 40017, write the account identifier and nothing from the account. The identity topic hub collects the related pieces.
The same rule applies when a leaver is involved. The record should let a reviewer decide whether the access should end with the person, and the piece on what happens when an employee change has no owner describes how often nobody is asked. An exception with a named owner survives the leaver process because the owner gets the question instead of an empty mailbox.
Service accounts and agents get the same treatment
The exceptions most likely to outlive everyone are the ones granted to accounts that are not people. The integration user from the migration. The credential a ServiceNow MID Server runs under. The account behind an agent that reads Dataverse tables on behalf of whoever asked. These grants are usually wider than any human's, and they never resign. The pattern does not change. A named owner, a date, a purpose, a reference. The argument for pausing agent work as an ordinary control depends on exactly this, because you cannot suspend an account cleanly if nobody can say who set it up or what it was for.
Start with the environment you can list this afternoon. Export the System Administrator assignments for one production Dataverse environment, and the users holding the admin role in one ServiceNow instance. Put both lists in front of the environment owner and ask, for each name, who owns this grant and when it ends. The names with no answer are your first exception records. In every review I have run, at least a third of the first list comes back unexplained, and that third is the meeting you should book next.
