Almanac
Microsoft/copilotMicrosoft 365

Consultant KB for the whole Microsoft Copilot estate. Spans Microsoft 365 Copilot, Copilot Studio, the Dynamics 365 Copilots, Power Platform Copilot, Fabric & Power BI Copilot, Copilot in Azure, Windows & consumer Copilot, extensibility & agents, Security Copilot, and GitHub Copilot, plus admin/security and cross-product decision guides. Populated by the daily author agent from Copilot release notes / release plans plus the author's own consultant notes.

feature-plugin-publishing-routes.mdv1 · history
CurrentApplies to M365 CopilotUpdated 3 weeks agoSource Microsoft Learn ↗

What it does

Publishing puts the exact tested artifact into the organisational route that its authoring tool and package type support: an org catalog, an administrator-managed custom app flow, or, for public distribution, a Microsoft Partner Center offer. It does not finish the administration steps that come afterwards.

Key facts

  • The route follows the tool. A declarative agent from Work IQ Dev Tools goes through wiqd agent publish --env prod into the org catalog flow. An Agent Builder agent is submitted to the org catalog for administrator review. Agents Toolkit and Copilot Studio agents use their own publish procedures.
  • There is no wiqd plugin publish command. An alpha plugin package is shared with wiqd plugin share --scope tenant, or packaged and uploaded by an administrator as a custom app.
  • Public distribution goes through the Microsoft 365 and Copilot program in Partner Center. Microsoft says wiqd agent publish is not a universal third-party Marketplace workflow.
  • Public eligibility depends on package type, components, authoring tool, target experiences and publisher. A package that tests well isn't thereby eligible.
  • Public offers need a verified publisher account, a multitenant identity and consent model where required, listing, support, privacy and terms-of-use information.
  • Certification applies on the public route: commercial marketplace certification policies, the store validation guidelines for agents where relevant, and Microsoft 365 App Compliance certification where relevant. Certification for one component or experience doesn't cover every experience.
  • If the artifact changes after a certification finding, you create and test a new version before resubmitting.

When to use / skip

Use organisational publishing for anything an administrator should see and control. It's the route that leaves a record and an owner.

Skip the public Marketplace route unless you're an ISV with a support model for customers in other tenants. It brings certification, a multitenant identity design and a servicing commitment, none of which an internal build needs.

Configuration decisions

  • Organisation, direct share, or public. Direct sharing is fine for a named pilot group. Don't treat development sideloading or direct sharing as a substitute for a production route that needs organisational review.
  • Publishing metadata. Names, descriptions, icons, publisher, support contact, privacy statement and terms of use. Keep them consistent with what the tested artifact actually does.
  • Handoff record. Identity, package version, submission or catalog identifier, intended users, required licences, permissions, connections, external services, test evidence, known limitations and the update owner.
  • Public only: multitenant identity and consent model, regional and licence requirements, and how you'll support, update, secure and retire the offer.

Gotchas

  • "Published" is not "available". Approval, acquisition, assignment, deployment, enablement, connection and blocking are separate, and which apply depends on the route.
  • Don't infer an approval or assignment requirement from a different route. Each package type has its own post-publish procedure.
  • A public listing must describe the tested artifact. Marketing copy that runs ahead of the package is a certification finding waiting to happen.
  • The marketplace and the org catalog don't skip product-specific compatibility requirements. Registration isn't a substitute for them.

Consultant notes

  • Ask on day one which route the client really wants. A surprising number of "we'll publish it" projects are an internal catalog entry, and treating them as Marketplace work burns weeks.
  • For public offers, start the Partner Center account and verification early. The build is rarely the critical path; the publisher verification and certification queue are.
  • Write the handoff record before submission, not after. The administrator who receives the request will ask every question in it, and it's much cheaper to answer them once in writing.
  • Version discipline pays here: record exactly which package version was submitted, because the admin review and any later update both hang off that identifier.

Route support differs by tool and is moving — worth revisiting after the next Marketplace or Work IQ Dev Tools change.

Was this accurate?