What it does

Governance policies evaluate outbound email against rules you define, and block, log or route for approval anything that violates them. It covers both AI-generated and representative-authored messages, extending the safety checks already used by autonomous agents to content a human wrote.

Key facts

• Customer Service only — this isn't available in Contact Center.
• Email channel only at present. Other channels aren't covered.
• Three enforcement behaviours: block the message with a dialog explaining which policies were violated, log the violation for reporting, or route for manual approval. Shadow mode logs without blocking.
• A blocked message can be overridden by the user, and the override is recorded. This is a guardrail, not a hard stop.
• Turned on in Copilot Service admin centre under Customer Support > Quality management > Governance.
• Administrators need the CSR Manager role; representatives need the Customer Service Representative role.
• Custom roles need explicit table privileges. Representatives need Read at global level on msdyn_governanceagent_status. Administrators need Read, Create, Write, Delete, Append, AppendTo and Assign at global level across msdyn_governanceagent_status, msdyn_guardrail_consumer_mapping, msdyn_guardrail_execution_info, msdyn_guardrail_rule, msdyn_guardrail_rule_version and msdyn_guardrail_scenariotype.
• Consumes Microsoft Copilot credits — pay-as-you-go has to be set up first.
• Requires consent for cross-region data movement, and AI agents enabled for the environment in Power Platform admin centre.
• Policies are expressed as descriptions that feed system prompts, so tuning a policy means rewording it and reviewing the detection logs, not editing a rule tree.
• If you replace the default Send button with a custom command, governance validation does not run. You have to call validateForSend from your own code, using the Governance_main_system_library web resource (shipped in the existing Activities Patch solution) added to the email form's form libraries. The returned validationResult tells your command whether to send or show the violation dialog.

When to use / skip

Use it where outbound email carries regulatory or brand risk and you already have AI drafting in play — it's the control that makes "let Copilot draft the reply" defensible. Skip it if your outbound email is templated and locked down anyway, because you'll be paying Copilot credits to police content that can't vary.

Configuration decisions

• Shadow mode or enforcing, and for how long. Shadow first is the only sane sequence — policies are prompt-driven and will false-positive before they're tuned.
• Whether representatives can override a block. The override is recorded, but it exists, so decide whether recording is enough for your compliance position.
• How policies are worded. This is prompt engineering, not rule configuration, and it wants an owner who'll iterate on it.
• Whether to grant the table privileges through the out-of-box roles or bolt them onto existing custom roles — most mature tenants use custom roles and will need the explicit privilege list.
• Whether any custom Send commands exist, and who owns fixing them.

Gotchas

• The custom Send command gap is the big one. A tenant with a bespoke Send button gets governance that silently doesn't run, with no error and no log — it just never fires. Nothing in the admin UI warns you.
• Overrides mean the block rate and the violation rate are different numbers. Report on overrides, not just detections, or you'll conclude the policies are working when people are clicking through them.
• Prompt-driven policies drift in effectiveness as message content changes. There's no versioned rule you can diff — the detection log is your only feedback loop.
• The privilege list for custom roles is long and global-level. Miss one table and the failure mode is unhelpful rather than explicit.
• Copilot credits are consumed per evaluation across all outbound email, not just AI-generated. Volume modelling based on AI-drafted messages alone will undercount badly.
• The feature documentation carries an explicit warning that it isn't for employment decisions. If a client asks to report on violations per representative, that's a conversation to have carefully and probably with their HR and legal people in the room.

Consultant notes

• Scope this against the client's actual outbound email volume, not their AI adoption. Costing it off "we expect 30% Copilot drafting" is the mistake — every email gets evaluated.
• Budget real time for shadow mode. Policies written in a workshop and switched straight to enforcing will block legitimate mail in week one, and the client's confidence in the whole AI programme takes the hit, not just this feature.
• Ask early whether anyone has customised the email Send command. On long-lived Customer Service tenants the answer is often yes and nobody remembers doing it. Find it before go-live, not after a compliance audit finds unvalidated mail.
• The override-and-record design is usually what gets this past a compliance function, so lead with it — but make sure someone owns reviewing the override log, or you've built an audit trail nobody reads.
• Sequencing dependency worth flagging in design: pay-as-you-go, cross-region consent and AI agents enablement all have to be in place first, and the first two often need a procurement or privacy sign-off with a lead time measured in weeks.

---

Worth revisiting after the next release wave — particularly for channels beyond email.