Policy Enforcer watches your governed Spaces while you're not looking and deals with every Policy breach the way you decided in advance.

Once an Enforcement is active, all of this runs without you.

Knowing how the watching works explains why some changes surface faster than others, and why the occasional Violation asks for a decision you weren't expecting.

💡If you haven't set up an Enforcement yet, start with Enforcements. Policy Enforcer only watches Spaces covered by a Policy you've chosen to enforce.

Once an Enforcement is active, Policy Enforcer checks for changes on its own, roughly every 10 minutes. OneNote and Planner renames run on a separate, slower cycle, so expect those two to take longer to appear.

💡OneNote renames need your Service Account. Without one connected under Settings, OneNote goes unwatched even when everything else is working, and nothing warns you. Confirm it's connected if OneNote naming matters to you.

Detection only ever looks forward. Policy Enforcer catches changes from the moment it starts watching a Space, and anything already in breach before that point is never picked up, no matter how long it's been there.

For the five auto-capable Violation Types, Policy Enforcer corrects the change itself and notifies your chosen Resolution Group.

A renamed Space is returned to its previous name. A Space that was made public is set back to Private, and a changed Sensitivity Label is reset to the one your Policy requires.

Occasionally the previous compliant value isn't available, and the Violation becomes a manual decision instead: your reviewers get a card, and nothing is lost.

If somebody puts the change right themselves before Policy Enforcer gets to it, nothing is overwritten. It checks the current value immediately before writing, sees it's already compliant, and closes the Violation without touching anything.

Manual resolution hands the decision to people. Your chosen Resolution Group gets an Adaptive Card, and any eligible member can open it and act.

The card shows what changed, what it changed from, and who changed it. Your reviewer picks the option that suits that Violation Type, either re-applying your Policy value or dismissing the Violation with a reason.

For the three types that involve owners and members, the options include re-adding whoever was removed and choosing a replacement from your directory. If that person has since been deleted from your tenant, they appear greyed out, with a note that they can't be re-added.

💡Adding somebody through the people picker also adds them to the Team if they aren't already a member. That's how the resolution gets applied, so give it a moment's thought before you pick a name.

Nothing is tied to a single reviewer. If the person who received the card loses access to the Space first, the Violation stays open and anybody else in the Resolution Group can resolve it.

Setting a Violation Type to Ignore records the change so you can see it happened, but corrects nothing, notifies nobody, and sends no card.

You might Ignore Planner renames on internal Teams where naming doesn't matter, while keeping them enforced on client-facing ones.

If a second change of the same type hits the same Space while the first Violation is still waiting, the older one is marked Expired, and the newer one takes over. There's little sense asking someone to fix a name that's already been renamed again.

Expired Violations move to the Resolved subtab and open read-only, so you can still see what happened. If a reviewer opens an older card and finds it closed, this is usually why.

Now that you know how Violations get caught and cleared, it's time to see where they actually turn up.

We recommend starting here:

Get further assistance with Policy Enforcer through our support chat widget within the app, or reach out to us at [email protected]