What it does

This is the administrator's half of the plugin lifecycle: what has to happen after a plugin or agent is published or shared before the intended audience can actually use it, who does it, and which control applies. Microsoft's point is that the answer changes by distribution route.

Key facts

• The lifecycle after publishing is: published or shared, then available and usable by the intended audience, then operated and improved, then updated and rechecked or retired. Governance applies throughout, and updates loop back through the same checks.
• Start from the publishing record: exact identity and version, publisher provenance, route, intended users or groups, target experiences, included components and their dependencies, required licences, permissions, consent and connections, responsible owners, known limitations.
• Next-owner logic: directly shared items are the publisher's and users' to confirm and connect; org catalog submissions are the administrator's to review, approve or publish, assign and configure; public Marketplace offers are the customer administrator's to acquire, assign, enable and configure; directly deployed connectors are the administrator's to create, configure and assign.
• Microsoft keeps lifecycle verbs distinct (review or approve, acquire, assign, enable, connect, block) and says not to apply an agent, app, tool or connector control to a different object unless its documentation says it applies.
• Different tools document different flows. Work IQ Dev Tools publishes to the org catalog so others can install it; Agent Builder has a separate submission, admin review, Agent Store publication and user install sequence.
• Direct connector deployment follows the Copilot connectors deployment guidance: create the connection, select users, configure content, manage synchronisation.
• Publisher responsibility is to supply the record, requirements, limitations and support owner. Administrator responsibility is to verify it and do only the actions the route needs.

When to use / skip

Use this as the runbook for any plugin or agent request that reaches the admin queue. It tells you what to check and what not to assume.

Skip any attempt to build one universal approval workflow for all agents and plugins. The routes differ enough that a single checklist will either block safe things or wave through unreviewed ones.

Configuration decisions

• Who can publish, who approves. Agree who reviews org catalog submissions and against what criteria, before the first request arrives.
• Audience. Named groups rather than everyone, at least for the first release of anything touching business data.
• Connections and external services. Decide who owns the connection, which identity it uses, and what happens when the external service is down.
• Update and retirement ownership. Name the owner for updates, access restrictions and removal at approval time, not at the point it's needed.

Gotchas

• Development sideloading and direct sharing aren't a production substitute where organisational review or assignment is required. A pilot that quietly became production is the usual way this goes wrong.
• A component can appear in admin inventories on its own, outside any plugin, with separate administration. Controls aimed at the plugin may not reach it.
• Missing publishing records are the most common blocker. If the information isn't there, the request goes back to the publisher; don't fill gaps by guessing.
• Approval doesn't equal availability. An approved item can still need assignment, enablement and a user-side connection before anyone sees it work.

Consultant notes

• Give clients a one-page intake form that mirrors the publishing record. It turns a vague "can you approve my agent" into a reviewable request and stops admins reverse-engineering what was built.
• Pilot the review process with a deliberately boring agent first. You learn who actually owns approval, and which team discovers they were never asked.
• Test as an intended user after assignment, not as the admin who just assigned it. Connection prompts and consent screens are invisible from the admin seat.
• Diarise a recheck for every published item. Updates loop back through the whole set of checks, and nothing about the lifecycle reminds anyone.

---

Admin guidance here is route-specific and still settling — worth revisiting after the next admin centre agent-management update.