Skip to main content
A governance model is the top-level container that holds the rules for a single data domain: its fields, its picklists, and its taxonomies. Define the rules once here, then expose them to the people who submit campaigns through workspaces. Most accounts run a single governance model.

​
What it is

A governance model groups together everything that defines one campaign-metadata standard:
  • Fields: the reusable definitions (text, URL, date, dropdown, short URL, QR code, and more). Each field belongs to one governance model. See Fields.
  • Picklists: the option lists that dropdown fields choose from. Each picklist belongs to one governance model. See Picklists.
  • Taxonomies: ordered groupings of fields that become the forms people fill in. Each taxonomy belongs to one governance model. See Taxonomies.
The governance model itself holds only a name and an optional description. The detail and structure live in its fields, picklists, and taxonomies. It is the definition layer, not the data layer: submissions and approved records live in workspaces, which consume the taxonomies a governance model exposes.

​
When to use it

  • You are setting up a new campaign-tracking standard and need one place to own its fields, picklists, and taxonomies.
  • You want every workspace to draw on the same set of rules (field types, validation, computed values like UTM strings and short URLs).
  • You need to keep two standards that share no fields fully separate. Create one governance model per standard.
Avoid creating multiple governance models when two standards share most of their fields. Fields, picklists, and references cannot cross from one governance model to another, so the sharing you want will not be possible.

​
Creating and editing

You create a governance model from the model picker in the sidebar.
1

Start a new model

Choose New, then Create from scratch for a blank model, or import an existing one (see below). A blank model needs only a name to start.
2

Add fields and picklists

Build the reusable field definitions and the picklists that feed your dropdown fields.
3

Assemble taxonomies

Create taxonomies that reference your fields in the order people should see them. See Taxonomies.
4

Publish a revision

Your edits stay as a working draft until you publish. Publishing a revision is what makes the current structure live for submissions. See Publish a revision.
To rename a model or change its description, open its Settings page. The name is required and must be unique within your account. Two different accounts may use the same name; within one account each governance model name is distinct. Creating, editing, importing, and deleting a governance model are admin actions. Any member of the account can view a model and export it.

​
Deleting a model

Delete a governance model from its Settings page, behind a confirmation. Deleting a model removes everything it defines: its fields, picklists, taxonomies, and shared links. This cannot be undone.

​
JSON import and export

A governance model can be saved to and rebuilt from a portable JSON file, so you can back up a model, move it between accounts, or hand a starting point to a colleague.
  • Export: from Settings, choose Export as JSON to download the model as a .json file. The export uses readable placeholder identifiers (gov_1, tax_1, fld_1, pkl_1) instead of internal IDs, and it includes the options inside your static picklists, so the file is a complete, self-contained copy.
  • Import: choose Import from JSON and upload a file. Import creates a brand-new model and all of its fields, picklists, and taxonomies in one step, rewiring every internal reference (parent picklists, computed-field sources, taxonomy field references) so the new copy is fully connected.
If you import a model whose name already exists in your account, the name is automatically suffixed: importing Marketing when Marketing exists creates Marketing (1), then Marketing (2), and so on. You never have to rename a file before importing it. Import is all-or-nothing. If any part of the file fails the checks, nothing is created and the error points at the field, picklist, or taxonomy that needs fixing.
Import and export are available on every plan. There is no paid-tier gate on moving a governance model in or out as JSON.

​
Gotchas

  • Deleting a model deletes its fields, picklists, and taxonomies. A governance model cannot be deleted while any of its taxonomies still has approved records, because a taxonomy with records cannot be deleted. Never delete a model that has live records in any workspace.
  • References cannot cross governance models. A field, computed-field source, picklist parent, or taxonomy field reference must stay within one model. Plan your model boundaries before you build. To move a field into a different model, recreate it there.
  • Names are unique per account. If a name is taken in your account, choose another. The same name is allowed in a different account.
  • The model is the definition, not the data. Submissions and records live in workspaces. To find “the records for Marketing,” go to the workspace records page, not the governance model.
  • Edits go live only when you publish. Day-to-day edits are saved as a draft and tolerate work in progress. Publishing a revision is the step that makes the structure live for new submissions. See Publish a revision.
  • Import runs stricter checks than everyday edits. Everyday editing lets you save partial drafts; import validates the whole model at once. An import error names the exact piece that breaks a rule.

Taxonomies

The ordered field groupings a governance model exposes as forms.

Fields

The reusable field definitions a model contains.

Picklists

The option lists that feed dropdown fields.

Publish a revision

How edits to a model become live for submissions.