Skip to main content
Every edit you make to a governance model lands in a draft: add a field, restructure a taxonomy, rename a picklist option. None of it reaches the people filling in submissions until an account admin publishes. Publishing freezes the draft into a numbered, read-only revision, and the submission builder always renders from a published revision, never from the draft you are editing.
Publishing snapshots the model’s structure (fields and their settings, taxonomies and their descriptions, picklist descriptions, how picklists link to fields) together with the options of every static picklist. Automated picklists are the one exception: their options always come live from their source taxonomy.

​
Draft versus published

A governance model has two layers:
  • The draft is what you see and edit in the designer. The field editor’s button reads Save to draft, and quick edits flash Saved to draft in the page header. Edits reach no submitters.
  • The latest published revision is what the submission builder reads. It changes only when you publish.
Everything you have edited since the last publish is your set of unpublished changes.
A governance model must be published at least once before anyone can submit against it. Until then, opening the submission builder reports that the model has no published revision.

​
The Draft/Publish bar

Every page inside a governance model shows a status pill and a Publish button in the page header. The pill reads: Terminus Hub revalidates the model shortly after each edit, so the pill stays current on its own. A dot next to Revisions in the sidebar mirrors it: amber when you have publishable changes, red when validation issues block publishing. If a check finds something worth a look that does not block publishing, a separate warning badge appears next to the pill. Examples are a dropdown default that names an option that no longer exists, a picklist that no field uses, or an option code whose casing differs from the rest of its picklist. Publishing is still allowed.

​
Review your changes

Click the pill to open the changes dialog without leaving the page you are on. It shows:
  • How many changes are pending since the last publish, and when and by whom that revision was published. Before the first publish there is nothing to compare against, so the dialog reads “Nothing to publish yet.” and Publish still creates revision 1.
  • One group per kind (Fields, Taxonomies, Picklists, plus Model when the name or description changed), listing each item with an Added, Changed, or Removed badge. Click an added or changed item to jump to its editor.
  • Any blocking issues under Publish disabled: N issues, and any warnings under Warnings.
  • Publish and Discard draft buttons.
The list is per item, not per setting: it tells you a field changed, not which setting.

​
Publish a revision

Prerequisites: you need to be an account owner or admin. Other members see the Publish button disabled, with a tooltip saying they don’t have permission.
1

Click Publish

Click Publish in the page header, or in the changes dialog. The button is enabled only when you have unpublished changes and no blocking issues.
2

Add an optional note

In the Publish governance model dialog, the Notes (optional) field asks “What changed?” The note is stored with the revision and shown in the history.
Make notes a habit. Something like “Added Campaign Owner field to the Campaigns taxonomy” tells the next person reading the history exactly what each revision did.
3

Publish

Click Publish. On success you see “Published as revision N,” the pill returns to Up to date, and the new revision appears in the history with a Live badge.
On an account with nothing published yet, you can also make the first publish from the setup review, which publishes the model and turns its taxonomies on in a workspace in one step. Every later change is published from the designer as described here.

​
Why a publish can be blocked

  • Validation issues. The pill reads Draft · N issues and Publish is disabled. The changes dialog and the Revisions page list each issue, linked to the item to fix. Typical causes: a taxonomy or field still refers to a field you deleted, or a picklist rule or option filter names an option code that no longer exists in the picklist. See Governance models for what a model needs to be valid.
  • Automated picklists on a plan without them. A model that contains an automated picklist can’t be published unless your plan includes automated picklists. The publish dialog shows Publishing needs a higher plan. Publishing stays blocked while the model contains one, even if no field uses it, so the alternative to upgrading is to remove the picklist.
  • No changes. If nothing differs from the latest revision, publishing fails with “No changes since revision N.” That includes editing something and then changing it back: the comparison is by value.
  • The draft changed. Publishing applies only to the draft you reviewed. If anyone edited the draft after you opened the changes dialog or the Publish dialog (another admin, a connected AI app, or you in another tab), nothing is published and the dialog says This draft changed. Click Reload editor to see the latest changes, then publish again. You see the same message if someone else’s publish or edit was still in progress.
Automated picklists require the Business plan or higher. See Plans and limits.

​
Discard a draft

Discard draft throws away every unpublished change and returns the draft to the latest published revision. Use it when an experiment went wrong or you want a clean start.
1

Open the changes dialog

Click the status pill in the page header.
2

Click Discard draft

The confirmation names how many changes will be reverted and the revision you are going back to, including picklist option edits.
3

Confirm

Click Discard draft. The pill returns to Up to date.
Like publishing, Discard applies only to the draft you reviewed: if the draft changed in the meantime, nothing is discarded and the dialog says This draft changed, with Reload editor. Discard only reaches back to the latest revision. It never creates, edits, or removes a revision, and you can’t use it to return to an older one. It is unavailable on a model that has never been published, and it needs the same permission as publishing. Because everything is recoverable until you publish, some edits that would break the model are allowed as draft changes. For example, deleting a field that other fields or taxonomies still use asks you to confirm Delete to draft: publishing is then blocked until you fix the broken references, or you can undo the deletion with Discard.

​
Picklist options are versioned

Static picklist options are part of the draft, like any other structure:
  • Adding, renaming, reordering, or removing an option shows up as a pending change and reaches submitters only when you publish.
  • Discard draft reverts option edits along with everything else.
  • Submitters are only ever offered the options in the published revision they are working against.
  • A record keeps the option label it had when it was approved, so renaming an option later does not rewrite existing records.
Automated picklists work differently. Their options come live from the approved records of their source taxonomy, so they never appear as draft changes and are not affected by Discard.

​
What happens after a publish

  • New submissions, and drafts that have not been approved yet, render from the latest published revision. A draft started before the publish picks up the new structure.
  • Approving a submission pins it, and the records it creates, to the revision in effect at that moment. That pin never changes.
  • The Revisions page shows the new revision with a Live badge. Earlier revisions stay in the history.

​
The Revisions page

Open Revisions from the governance model’s sidebar to see every published revision, newest first. Each row shows: The history is read-only. You can’t edit, delete, or restore a past revision, and there is no separate “activate” step: the newest revision is always live. When validation issues are blocking a publish, the page also shows a Publishing blocked by N validation issues card listing them. There is no cap on how many revisions you can publish. If you publish often, consider batching related changes into one revision so the history stays readable.