Taxonomies

​

What it is

A taxonomy sits in the middle of a governance model. The model owns the reusable fields; a taxonomy picks a subset of those fields, puts them in an order, and presents them as a form. Fields are not attached to a taxonomy directly. Each field is added through a field reference, a lightweight link that records the field’s position (its order in the form) plus any per-taxonomy overrides. Because the link is lightweight, the same field can appear on several taxonomies, each with its own order and its own dropdown-option filtering. The field definition is never duplicated. A taxonomy becomes usable once it is connected to a workspace. Submissions and approved records always belong to one taxonomy and one workspace. That pairing decides which form a person sees and which records they can work with.

​

When to use it

• A workflow needs a specific combination of fields (for example, email campaigns need a utm_medium, while QR codes are only useful for social posts).
• Two teams share most of the same rules but need small variations in which fields appear or which dropdown options are offered.
• You want field definitions to live in one place (the governance model) while different forms expose different combinations to different workspaces.

​

Creating and structuring a taxonomy

Open the Taxonomies list for a governance model and choose Create new. A taxonomy needs a name, which must be unique within its governance model, and may have an optional description shown as help text in the form. After creating it you land in the editor. The editor has two panes: a searchable, drag-sortable list of fields on the left, and a live preview of the form on the right. Add fields from your governance model, then drag them into the order you want. The order persists as each field reference’s position. A field used in more than one taxonomy shows a Shared field badge, a reminder that editing the field changes it in every taxonomy that uses it. Rename or re-describe a taxonomy later from its Settings tab.

​

Per-taxonomy field overrides

A field reference can adjust how its field behaves in this one taxonomy without changing the field itself:

• required and hidden can be tightened per taxonomy. You can make a field required or hidden here, but you cannot loosen a field that is already required or hidden in its own definition.
• filter_options restricts which picklist options a dropdown offers in this taxonomy, without editing the master picklist.

filter_options is valid only on dropdown fields. See Field-reference overrides for the full behavior, including how include and exclude differ.

​

Connecting to workspaces

A taxonomy is exposed to submitters by connecting it to one or more workspaces, done from the taxonomy’s Settings tab or from the workspace side. Each connection carries its own settings for that taxonomy-and-workspace pair:

• Review required: when on, submissions to this taxonomy in this workspace go through the approval flow before they become records. See Review and approve submissions.
• Per-workspace dropdown filtering: the same kind of option filtering as filter_options, scoped to one workspace.

Turning review required on requires your plan to include approval workflows. Turning it off is always allowed, so an account that downgrades can switch review off and unblock its members. See Workspaces for how a workspace curates the taxonomies assigned to it.

​

Cloning a taxonomy

Use Clone to copy a taxonomy within the same governance model. The clone copies every field reference together with its overrides (required, hidden, filter_options). It deliberately does not copy workspace connections: the clone starts attached to no workspace, so cloning never accidentally re-exposes a form. Give the clone a name that is not already used in the model.

​

Gotchas

• You cannot delete a taxonomy that has records. Deletion is blocked as long as any approved record references the taxonomy. Remove or move the records first.
• At most one Short URL field per taxonomy. A taxonomy models one tracking-link shape, so a second Short URL field is not allowed. If you need a second link, put it on a separate taxonomy.
• Updating fields or workspaces replaces the whole set. When you save the field list or the workspace connections, the editor sends the complete set and reconciles by difference: anything you leave out is removed. The editor handles this for you; it matters only if you are scripting against the structure directly.
• Field dependencies must be present. If you add a computed field, every field it relies on (its sources, the picklist it filters, and so on) must also be in the taxonomy. The list page and the dependency diagram flag a missing dependency. Check after adding or removing fields.
• Overrides only tighten. A taxonomy can make a field required or hidden but cannot un-set a field’s own required or hidden setting. Attempting to loosen it is rejected.
• filter_options is dropdown-only. Setting it on any non-dropdown field is rejected.
• Cloning drops workspace connections by design. Reconnect the clone to its workspaces before anyone can submit against it.

​

Related