A workspace is a named sub-division inside your account: a team, brand, region, or client. It connects one or more taxonomies and scopes the submissions, records, and members that work within them. Your account owns the taxonomy definitions; a workspace is the place people actually work inside them.
What it is
An account contains one or more workspaces. A workspace is the unit you work inside: it connects (assigns) one or more taxonomies, and every submission and record belongs to exactly one workspace. Use workspaces to split work by team, brand, region, or client while sharing the same account-level taxonomy definitions.
Every new account starts with one workspace named Main. It is an ordinary workspace, so you can rename, clone, or delete it like any other.
A workspace does not belong to a governance model directly. Its connection to a governance model is implicit, carried through the taxonomies you assign to it. See Data model for how accounts, governance models, taxonomies, workspaces, and records fit together.
Creating and naming a workspace
Account owners and admins create a workspace by giving it a name (and an optional description), then assigning the taxonomies it should collect submissions for.
- The name is required and must be unique within the account.
- A workspace with no taxonomies assigned cannot collect submissions. The settings form, the sidebar, and the records page all nudge you to assign at least one.
On some plans the number of workspaces is capped. Hitting the cap shows a “Workspace limit reached” prompt instead of creating the workspace.
Connecting taxonomies
From the workspace settings form you pick which taxonomies the workspace uses. The assigned set is replaced in full on each save: the list you save is the complete desired set, so removing a taxonomy from the list removes its connection (and any per-workspace settings on that connection).
Per-workspace field overrides
Each taxonomy-to-workspace connection can carry field overrides that change which dropdown options appear for a field, in that workspace only. The same taxonomy can therefore show a different subset of options in different workspaces.
The override is an option filter per field, in one of two modes:
| Mode | What it does | New options added later |
|---|
include | Show only the listed option codes (an allowlist). | Hidden until you add them to the list. |
exclude | Show every option except the listed codes (a blocklist). | Appear automatically. |
Require review per taxonomy
Each taxonomy-to-workspace connection also has a require review toggle.
- When off (the default), submissions for that taxonomy in this workspace publish directly.
- When on, those submissions go through the review and approval flow instead. See Review and approve submissions.
Turning review on requires a plan that includes approval workflows. Turning it off is always allowed, so a downgraded account can unblock its members.
Cloning a workspace
Cloning creates a copy in the same account under a new name. Only configuration is copied: the taxonomy connections and their per-workspace field overrides.
Cloning copies the assigned taxonomies and their option filters. It does not copy members, records, or submissions, and it does not carry over the require-review setting. Cloned taxonomy connections start with review off, so re-enable review on the clone if you need it.
<name> Copy.
Members and roles
Each member’s access to a workspace is set per workspace, with one of three roles:
| Role | What they can do |
|---|
admin | Manage the workspace (edit settings and assigned taxonomies), plus everything below. |
member | Create and edit submissions within the workspace. |
viewer | Read-only access to the workspace. |
- A member has at most one role per workspace, and it defaults to
viewer when not set.
- Account owners and admins have access to every workspace automatically. They are never given per-workspace roles. Only account-level members get explicit per-workspace assignments.
You assign per-workspace roles when you invite or edit a member, on the account team pages, not on the workspace itself. For account-level roles and the invite flow, see Team members.
Who can see and manage a workspace
- Account owners and admins can create, clone, update, and delete any workspace, and see all workspaces.
- A workspace
admin can update that workspace’s settings.
- Everyone else sees only the workspaces they are a member of. Opening a workspace you are not a member of is not permitted.
Deleting a workspace
Deleting a workspace is a confirmed, destructive action. A workspace deletes cleanly only when it is empty: if it still owns records, submissions, or member assignments, the delete is blocked and you see an error. Remove or move that content first.
Gotchas
- Assigned taxonomies are replaced, not merged. Saving the settings form sends the complete desired set. Leaving a taxonomy off the list removes its connection and the per-workspace overrides on it. Saving an empty list removes every connection.
- Cloning drops the require-review setting. A clone copies taxonomy connections and option filters only. Review starts off on the clone, and members, records, and submissions are not copied.
- A workspace with no taxonomies can’t collect submissions. Watch for the “No taxonomies assigned” prompt and the marker on the workspace’s settings link.
- Two different role ladders exist. Account roles (owner / admin / member, see Team members) are separate from per-workspace roles (
admin / member / viewer). A workspace viewer is read-only; there is no account-level “viewer”.
- A workspace admin is not an account admin. A workspace admin can edit that workspace but cannot create new workspaces or change account settings.
- You can’t delete a populated workspace. Records, submissions, and member assignments block deletion until they are removed.
- Enabling review can be plan-gated. If the toggle won’t turn on, your plan may not include approval workflows. Turning review off is always allowed.
- Taxonomies: the definitions a workspace connects and collects submissions for.
- Data model: how accounts, taxonomies, workspaces, and records relate.
- Submissions: created and edited inside a workspace, subject to its roles and review setting.
- Records: the approved rows a workspace holds, partitioned per workspace.
- Field reference overrides: the per-connection option filters in depth.
- Team members: account roles and where per-workspace roles are assigned.
