What it does

This is the up-front requirements exercise for a Copilot plugin: map where data and actions flow, decide identity and permissions, check compliance obligations, plan for consequential actions, and note the governance outcomes admins will need. Microsoft positions it as something you do while planning, before you've chosen components or tooling, and then carry forward into validation.

Key facts

• Document data flows for prompts, conversation history, Microsoft 365 data, external organisational data, generated content, actions, logs and support data. For each flow record owner, source, destination, location, classification, retention, deletion, encryption, availability and failure behaviour.
• Component-specific questions differ. Agents: which instructions, knowledge, context, actions and services. Skills: which inputs, outputs and host permissions. Copilot connectors: synced into Microsoft Graph or federated, and how item-level access is enforced. MCP-based capabilities: what's exposed, what data is sent, where the server runs. APIs: operations, credentials, customer data, logs, providers.
• Identity planning covers user, application, package, publisher, service and administrator identities, Entra registrations, scopes and consent, delegated versus application access, secret and certificate rotation, and what happens when authentication fails.
• A plugin doesn't grant a user access to anything they weren't already entitled to. Microsoft Graph and Microsoft 365 services enforce identity-based boundaries on data they hold; externally hosted services are responsible for their own.
• Consequential actions (create, change, send, approve, purchase, delete, disclose) each need permitted users, validation, confirmation or human oversight, safe failure and reversal, evaluation criteria, and monitoring and suspension procedures.
• Public or multitenant plugins add a privacy statement, terms of use, publisher identity, customer consent, support model, security response and certification requirements, including Marketplace certification policies and Microsoft 365 App Compliance Program.

When to use / skip

Use it at the start of any plugin that touches business data or can take actions, and hand it to the security and compliance owners early. It's a good intake template.

Skip it as a substitute for validation. It tells you what to ask; the implementation checks come later with plugin validation and the product-specific security guidance.

Configuration decisions

• Federated or synced. For connectors, choose whether content is copied into Graph or queried live, because it changes retention, permissions mapping and outage behaviour.
• Where remote servers run. For MCP-based capabilities, settle hosting location and what leaves the tenant before anyone writes code.
• Confirmation model. Decide which actions need an explicit user confirmation and which need approval from someone else.
• Distribution scope. Internal line-of-business and public plugins have very different obligations; decide which you're building before drafting the requirements.

Gotchas

• "Respects permissions" only holds inside Microsoft's boundary. An external API that ignores user identity will happily return everything to everyone.
• Prompts and context sent to external services and MCP servers are data egress, whatever the architecture diagram calls them.
• Unresolved requirements that depend on the chosen components get forgotten. Microsoft explicitly says to track them and revisit at validation.
• Governance outcomes (review, assign, restrict, retire) need an owner named at planning time; the admin surfaces vary by component and won't pick one for you.

Consultant notes

• Run the data flow table as a workshop with the security architect and the plugin owner in the same room. Two separate reviews produce two different diagrams.
• The consequential action list is where UAT should spend its time. Clients test the happy path of search and read and discover the send/delete path last.
• Capture external service log retention early. It's a regular late surprise in privacy sign-off, especially with third-party MCP servers.
• Keep the requirements register alive through build. If it isn't referenced at validation, it was theatre.

---

Planning guidance sits alongside fast-moving component and tooling choices — worth revisiting after the next extensibility documentation update.