Skip to main content

​
What it is

The mental model:
  • Account - your user. Can belong to many workspaces.
  • Workspace - the unit of isolation. All links, folders, tags, templates, UTM rules, custom domains, pixels, API keys, analytics, billing, and members live here.
  • Member - a user attached to a workspace with a role (owner, member, custom).
  • Folders - sub-organization within a workspace.
There’s no concept of “organization” above workspace. Run multiple workspaces (e.g., per client, per brand) on one account.

​
When to use multiple workspaces

One workspace per client. Their links/domains/templates/billing isolated. Owner moves between workspaces from the workspace switcher.

​
Real-world example

Acme Marketing Agency: 
Account: jane@acme-agency.com
Workspaces:
├── Acme Internal       (slug: acme-internal)        - owner: jane
├── Client: Globex      (slug: client-globex)        - owner: jane
├── Client: Initech     (slug: client-initech)       - owner: jane
└── Client: Soylent     (slug: client-soylent)       - owner: jane

Each workspace:
├── Members (with per-client account managers)
├── Domains (each client's branded short domain)
├── Templates (per-client UTM presets)
├── UTM Rules (per-client naming convention)
└── Plan & usage (billed per workspace)

​
Common mistakes

Creates billing fragmentation and member-management overhead. Use folders.
Defeats data isolation. Members of Client A can see Client B’s links.
Slug is the URL identifier (acme-internal). Name is the display name (Acme Internal). They’re independent.

​
Edge cases

Workspace name unique per owner. You can’t own two workspaces with the same name (case-insensitive). Different owners can.
Slug uniqueness. Slugs are globally unique across linkutm.