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 prodinto 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 publishcommand. An alpha plugin package is shared withwiqd 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 publishis 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.