Skip to main content

Publishing

Publishing turns a bundle of your resources into a catalog template — a listing with a name, screenshots, and release notes that other companies can discover and install. Public listings go through Autessa review; company-only and private drafts don't.

What it's for​

If you've built something worth reusing — a support workflow, a CRM on AutessaDB, an app — publishing is how you distribute it at scale. The publish flow captures your resources into a versioned manifest, collects listing metadata, and manages the review lifecycle from submission to going live.

Two paths lead to the same place:

  • From the export wizard — select resources under Marketplace → Export bundle and choose Publish to marketplace at the review step. This is the primary flow.
  • The create wizard at /marketplace/create — a four-step version of the same thing: select resources, preview the manifest, fill in metadata, review and submit.

Your existing templates live under the catalog's My templates tab; each template's detail page has a Manage menu for editing, versioning, and submitting.

Key concepts​

  • Listing metadata — a template has a name, a URL slug (auto-derived), a short description shown on cards, a markdown long description, an optional category, tags, a 16:9 cover image, up to 6 screenshots (each cropped 16:9, 8 MB max per image), and optional setup instructions.
  • Visibility — at publish time you pick one of three: Save as draft (private), Publish to your company (visible and installable inside your company only), or Submit for public review. Public submissions include submission notes for the reviewer.
  • Review lifecycle — a submitted template is pending review until an Autessa admin approves (it goes live in the public catalog, optionally featured) or rejects it (you'll get the reasoning in the review thread on your template page, fix things, and resubmit). Live templates can later be suspended by admins and reinstated. Once a template has a published version, review of a new version never takes the existing version away from installers.
  • Versions — the first publish creates version 1.0.0. New versions default to a patch bump (1.0.0 → 1.0.1) with a What changed changelog that becomes the release notes readers see. Each version is a freshly captured bundle and is reviewed independently. Draft and rejected versions can be deleted; a template that was never public and has no installs can be deleted entirely.
  • What travels — the manifest captures your resources as they are at publish time. Secrets are stripped exactly as in a bundle export, and custom apps are pinned to their latest published version — publish the app first.

How to publish a template​

  1. Open Marketplace → Export bundle, select your resources, and review the dependency preview — everything shown will be part of the listing.
  2. Click Publish to marketplace.
  3. Fill in the listing: name, short and long descriptions, category, tags, cover image, and screenshots.
  4. Choose visibility — draft, company, or Submit for public review (add submission notes explaining what the template does and how you tested it).
  5. Submit. Drafts and company templates are usable immediately; public submissions appear as Pending until reviewed, and you'll be emailed on approval or rejection.

How to release a new version​

  1. Open your template's detail page and choose New version from the Manage menu.
  2. The export wizard opens pre-seeded with the previous version's resources — adjust the selection if the workflow changed.
  3. In the publish dialog, confirm the version number (a patch bump is suggested) and write the What changed changelog. Cover image and screenshots carry forward; update them if the UI changed.
  4. Submit for review. Your currently published version stays live for installers until the new one is approved.

Making listings people trust​

Installing a template means creating real resources in someone's company, so the listing has to earn that trust:

  • Screenshots are the showcase — capture the actual installed experience (the app, the agent conversation, the table) rather than logos or abstract art. Use all six slots if the template has that much surface.
  • Write release notes like a changelog, not a commit message — every version's notes are public on the detail page. Say what changed and why an installer should care.
  • Make the long description answer "what will this do to my company?" — the dependency diagram and resource breakdown render automatically, but your description should explain what each major piece is for and what connectors or credentials the installer must bring.
  • Include setup instructions for anything the install can't do itself: connector authentication, secrets to obtain, configuration to review after install.
Reviewers install your template into a clean company. If it needs undocumented setup to work, that's the most common reason for a rejection.