A revision is how your structure goes live. Until you publish, your changes are drafts that only you and other editors see. Publishing snapshots the structure (fields, taxonomies, links, prefixes, suffixes, required and hidden settings) into the next revision number, and submitters start using it for new submissions.
Draft versus published
There are two layers to a governance model:- The live model you edit in the builder. Edits take effect immediately for editors but reach no submitters.
- The published revision the submission builder reads from. This only changes when you publish.
The unpublished-changes indicators
Terminus Hub revalidates your model continuously as you edit (debounced shortly after each change), so the publish indicators stay current without you doing anything.- Sidebar dot. A dot appears next to the Revisions nav item whenever you have unpublished changes. It is amber when the model is valid and ready to publish, and red when there are validation issues blocking the publish.
- Header status badge. The model header shows one of:
- Up to date (green): no unpublished changes, the live model matches the latest revision.
- Ready to publish (amber): you have valid unpublished changes.
- Publish disabled: N issues (red): unpublished changes exist but validation is failing. Click it to open the issue list.
- Publish card. On the Revisions page, a publish card appears only when you have unpublished changes. It is where you actually publish.
View revision history
Open the Revisions page
From inside your governance model, open the Revisions tab. You will see every published revision, newest first.
Read the revision table
Each row shows:
| Column | Description |
|---|---|
| Revision number | Auto-incremented, starting at 1 |
| Published at | Date and time the revision was published |
| Published by | The user who published it, when that can be determined |
| Notes | The optional note entered at publish time |
| Status | A Live badge marks the current revision (the highest number) |
The newest revision is always the live one. There is no separate “activate” step: publishing makes the new revision live immediately.
Publish a revision
Prerequisites: you need account-admin permission to publish. The publish button is hidden if you cannot publish, and the model must have unpublished changes (otherwise there is nothing to publish).Open the publish card
Make your edits, then go to the Revisions page. The publish card is there whenever you have unpublished changes. If validation is failing, the card lists the blocking issues instead of a publish button (see below).
Add an optional note
In the publish dialog, the Notes (optional) field answers “What changed?” The note is stored with the revision and shown in the history. A one-line summary makes the history far more useful when you audit it later.
Why a publish can be blocked
Publishing runs a validation check, and a failing model cannot be published. Two situations stop a publish:- Validation issues. If the structure has errors (for example a
dropdownfield with no picklist linked, or aconcatenationfield referencing a field that no longer exists), the publish card turns into a red “Publishing blocked” card listing each issue, with no publish button. Fix the highlighted issues, then publish. See Governance models for what the model needs to be valid. - No changes. If you open the dialog and try to publish when nothing differs from the latest revision, publishing fails with “No changes since revision N.” This includes editing something and then changing it back to exactly how it was: the snapshot is compared by value, so an edit that nets to nothing is treated as no change.
What is and is not in the snapshot
A revision freezes the model’s structure: its fields and their settings, its taxonomies, how picklists link to fields, and the prefixes, suffixes, required, and hidden settings. Picklist options are intentionally not in the snapshot. Options are treated as content, not structure. The practical consequences:- Editing an option’s label, soft-deleting an option, or accepting a user-proposed addition does not require republishing. Those changes take effect for submitters right away.
- The submission form loads picklist options live, so submitters always see the current set of options regardless of which revision they are on.
- Because options are excluded, editing only picklist options leaves your model showing Up to date with nothing to publish.
What happens after a publish
Once a new revision is live:- New submissions render from the new structure.
- Submissions and records that were already created are pinned to the revision they were started against, and that pin does not change. In-progress work keeps the structure it began with rather than shifting under the submitter.
- The Revisions list shows the new revision with a Live badge, and the previous revision stays in history for reference.
Revision rules and limits
There is no hard cap on how many revisions you can publish. If you publish often, consider batching related structure changes into one revision so the history stays readable. If two people publish at the same time, Terminus Hub serializes the publishes so revision numbers never collide. If your editor was behind, you may be told another revision was just published; reload the editor to pick up the latest, then publish again.Related
- Governance models: the structure that a revision snapshots, and what makes it valid to publish.