> ## Documentation Index > Fetch the complete documentation index at: https://docs.terminus.app/llms.txt > Use this file to discover all available pages before exploring further. # Taxonomies > A named, ordered grouping of a governance model's fields that becomes a submission form, connects to workspaces, and sets whether submissions need review. A taxonomy is a named, ordered grouping of fields inside a governance model. It is the concrete form shape people fill in to create records. A taxonomy can adjust individual fields with per-taxonomy overrides, connects to one or more workspaces, and controls whether submissions to it need review. ## 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. If two workflows share almost no fields, they are really two separate standards. Consider two governance models instead of two taxonomies. ## 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](/reference/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](/guides/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](/reference/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 How `filter_options`, `required`, and `hidden` work per taxonomy. Where taxonomies are connected and used. What review required turns on for a taxonomy. The container that owns a taxonomy's fields.