Teammates & access
Everyone you invite is a teammate; what varies is their privileges. Grant the workspace-admin privilege to teammates who manage the team, set per-teammate capabilities, and use the access checklist to control which file categories and case-data fields each person sees. Clients are external seats that only see the portal.
The app has no job-title roles to memorize. A workspace has one owner (the account that created it), the teammates you invite, and external clients on the portal. Teammates aren't sorted into named tiers: each one carries their own set of privileges, and the dashboard's Team view is where you set them. Inviting teammates or changing privileges requires the owner or a workspace admin. New to the team/case vocabulary? See core concepts.
The three kinds of seats
- Owner: full control: billing, integrations, team membership, and every case, template, and workspace setting. Set automatically on whoever created the workspace; never selectable when inviting. Transfer ownership by contacting support.
- Teammate: everyone else you invite. What they can see and do is set per person (below). A teammate granted the workspace admin privilege manages the team and workspace alongside you: they can invite teammates, edit templates and workspace settings, and always see every category and field. Admins cannot change billing; that stays with the owner.
- 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 roster.
What you can set per teammate
Open the dashboard's Team view (the last tab in the view switcher, after Analytics) and expand a teammate's card:
- Workspace admin: one checkbox under Access. On, they manage the team and always see everything (no checklist). Off, they're a regular teammate whose visibility you can scope.
- Capabilities (inside Configure Access): Read Cases, Update Cases, Delete Cases, Add Activity, Sensitive Data, Compose Emails. New teammates start with read and activity; grant more as needed.
- Workspace access and dashboard views (same panel): which workspaces they can open, and which dashboard views (Map, Calendar, Analytics) they get beyond Details.
- Assigned cases only (same panel): restrict them to cases they're added to (Layer 1 below).
- Access checklist: which file categories and case-data fields they see (Layer 2 below).
- Deactivate: the red button in the expanded card header removes their access without deleting history; Reactivate restores it.
Inviting teammates
The Teammates heading shows occupied seats over the seat limit, and Add teammate handles upgrades, seat adds, and invites.
Pending invites stay in the Team list until accepted; if someone never signs in, resend from the same panel.
Restricting a teammate
Layer 1, which cases. By default every teammate sees every case in every workspace they can access. Open the teammate's card in the dashboard's Team view, click Configure Access inside it, tick Only show cases assigned to this teammate, 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 categories and fields. Every teammate and client has a baseline access set, editable from the dashboard's Team view (owner/admin only): a card per teammate lists every file category and every case-data field as a checklist, and a single Clients card sets the one baseline every portal client inherits. Workspace admins always see everything and have no checklist. Teammates default to seeing everything until you narrow their card; clients default to seeing nothing until you grant categories and fields. A per-case override, edited from that teammate's or client's row in the case's Team or Clients panel, can narrow or widen the workspace baseline for that one case only (⋯ menu → Edit visibility). Hiding a category also hides activity events referencing files in it, drops it from inbox case-card chips, and blocks AI chat tools from surfacing those files. These category and field controls are applied by the app's case views; unlike Layer 1, Firestore cannot redact individual fields from an allowed document.
The layers compose: a teammate might be limited to 12 cases via Layer 1, and see different categories and fields on each via a per-case override on top of their Team-view baseline.