What it does

The administrator's view of the plugin lifecycle: define requirements early, identify the exact object being published, make approved solutions available, configure connections, apply controls, monitor use, and retire safely. A companion page covers monitoring, updating and retiring a deployed plugin or agent (https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/improve-plugin).

Key facts

• Identify the object before applying a control: plugin package, agent, skill, MCP server, connector, connection, external service, or Microsoft 365 app. Each can sit on a different administration surface.
• Controlling one object doesn't automatically control referenced components, connections, external services or runtime dependencies.
• Start from the builder's publishing record: object identity and exact version, publisher, route, intended users, supported experiences, included components, licences, permissions and consent, connections, limitations, and support and update owner.
• Not every route needs review, acquisition, assignment, enablement or connection. A per-user connection isn't an organisation-level deployment, and package availability and component controls can be separate operations.
• Monitoring is per object: wiqd agent monitor (experimental) for provisioned declarative agents, Agent Builder's monitor tab, the agent registry for inventory, the Insights Agent for aggregate usage, MCP tool activity under tool management, and connector settings for sync. There's no single dashboard.
• Availability, assignment or installation isn't evidence of adoption.
• Updates re-enter Package and test. A functional change goes through packaging, validation and testing again before republishing. A shared version and an org-catalogue version can have different approval states.
• Rollback and restore aren't available for every object or route. wiqd plugin has no rollback or publish command.
• Retirement is complete when users can't reach the object, dependencies are removed or reassigned, and the final state is recorded.

When to use / skip

Use it as the checklist behind your plugin intake process. Skip it as a procedure source; the page says to use the linked product administration articles for current labels and steps.

Configuration decisions

• Allowed distribution scopes and capability types, written into the plugin solution brief.
• Review, approval and exception process, and who owns each.
• Support and lifecycle owners, and ownership-transfer procedure where the product allows it.
• Evaluation: rerun agent quality evaluations when instructions, knowledge, tools or dependencies change, if you need evidence a change helped.
• Retirement checklist covering connections, app registrations, permissions, service accounts and external-service access.

Gotchas

• Blocking an agent doesn't switch off the external service behind it or remove indexed data.
• Transferring one agent or catalogue record doesn't transfer every component, credential or dependency.
• Agent-specific usage reports say nothing about each component in a plugin.
• Assuming one approval or block propagates across every Microsoft experience. Only the linked procedure can confirm that.

Consultant notes

• Build the intake form around the publishing record fields above. Reviewers who approve a name and a description have approved nothing.
• Name an owner for every connection and external service at approval, not at the first incident. Orphaned service accounts are the usual retirement leftover.
• Don't report "deployed" as adoption in steering packs. Agree up front which signal you'll use per object, knowing it'll differ across them.
• Run a retirement dry run on a pilot plugin. You'll find out which dependency nobody owns while it's cheap.

---

Review when the administrator guidance, the monitoring surfaces or rollback support for plugins and agents change.