Roles & permissions

Every seat is one of four roles: Owner, Member, Worker, or Client. Owner and Member manage the team and edit cases, Worker works cases (and can be scoped), Client is external and only sees the portal.

Updated 3 min read

Changing a role, inviting teammates, or scoping a worker all require Owner or Member access. New to the team/case vocabulary? See core concepts.

The four-role model is one tier (Owner/Member) for people who shape the workspace, one (Worker) for people who work inside it, and one (Client) for external eyes on the portal.

The four roles

  • Owner: full control: billing, integrations, team membership, and every case, template, and workspace setting. Set automatically on whoever created the workspace; never selectable from the invite picker. Transfer ownership by contacting support.
  • Member: same case and configuration access as Owner (read, update, delete cases; edit templates; configure workspaces; invite teammates) but cannot change billing.
  • Worker: reads cases and adds activity, but cannot update or delete them. Optionally restricted to assigned cases and to a subset of file categories per case. Use for staff who shouldn't reshape the data.
  • Client: external seat. Signs in at /portal, sees only shared cases, the file categories granted, and forms exposed for them to fill. Never appears in the Team panel.
The role matrix
Ownerbilling + team + cases + config
Memberteam + cases + config
Workercases (read + activity), optional restrictions
Clientportal access to shared cases only

Inviting members and changing roles

Open Settings → Account and expand the Team section ("Manage members, seats, and invites").

1In the Invite form, enter the email (e.g. riley@acme.com)
2Pick a role, Worker or Member (Owner isn't selectable; ownership is set when the workspace is created)
3Click Send invite. They get an email with a sign-in link and join the workspace automatically on first sign-in
4To change an existing seat, pick Worker or Member from that member's role select; it saves on selection

Pending invites stay in the Team list until accepted; if someone never signs in, resend from the same panel.

Restricting a worker (two layers, both server-enforced)

Layer 1, which cases. By default every member sees every case in every workspace. Open the worker's row in Settings → Account → Team, click Configure Access beneath it, tick Only show cases assigned to this member, and click Save Configuration. They then see only cases where they appear in the case's Team panel: unassigned cases are unreachable via search, the API, or a direct URL, not just hidden. Assign them through each case's Team panel, picking visible categories at the same time.

Layer 2, which files on an assigned case. When you add a worker to a case's Team panel you pick the visible file categories (permit, invoice, inspection_report, ...). That list drives every view on the case: files outside it are hidden, activity events referencing hidden files are filtered out, inbox case-card chips drop hidden categories, and AI chat tools refuse (ask about a file you can't see and the assistant says you don't have access). To adjust later, open the case, find the worker's row in the Team panel, use the menu and pick Edit visibility, toggle categories on/off, and click Save (applies on their next page load).

The layers compose: a worker might be limited to 12 cases and see different categories on each.

A restricted worker across two cases
Memberriley@acme.com
RoleWorker
Assigned cases onlyon
Case A visible categoriespermit, invoice
Case B visible categoriesinspection_report
We use cookies to keep you signed in and improve the product. See our Cookie Policy.
Manage preferences