Roles & access

This page explains how access control works on Fola — what a role is, how one is granted, and which roles exist.

If you’re a firm owner or admin inviting your own team, you don’t need most of this: the invite flow on Settings → Members hasn’t changed, and neither has what each firm role can do. Start with Day 2 — Building your team instead.

The model in one paragraph

Every action in Fola (view a client, edit billing, flip a feature flag) is a permission. Permissions are bundled into named roles — Attorney, Paralegal, Platform admin, and so on. A role is given to a person as a grant (sometimes called a binding): the role, plus a scope that says where it applies. A person can hold any number of grants at the same time, and each grant is added and removed independently.

Scopes

Every grant applies at exactly one scope:

Scope	The role applies to…
Platform	Everything, everywhere. Reserved for Fola-internal roles.
Firm	One specific firm — its members, clients, and cases.
Case	One specific case only.

Because grants stack, one person can be a Firm Admin at their firm and a Translator desk member — those are two separate grants, added and revoked on their own, each with its own audit trail.

The role catalog

Firm roles

These are the roles you pick when inviting a team member. Their capabilities are unchanged — the same roles gate the same features (billing, members, clients, credentials, feature flags, PDF lock, audit log) as before.

Role	What it’s for	Scope
Owner	Everything, including billing + ownership transfer. One per firm.	Firm
Admin	Everything except billing + ownership transfer.	Firm
Attorney	Manage cases, sign filings, firm-wide client list.	Firm
Paralegal	Prepare cases, draft filings, edit profiles.	Firm
Viewer	Read-only across the firm.	Firm

Client visibility. Separately from roles, each firm chooses how far client access reaches: Settings → Organization → Client visibility toggles between everyone at the firm sees all clients and members see only clients assigned to them. With visibility limited, attorneys and paralegals can open only their assigned clients — the ethics wall that keeps conflict-of-interest screens intact — while owners and admins always see everything either way.

Desk roles (Fola-internal)

Desk roles put Fola staff on an internal work queue. Firms never assign these.

Role	What it’s for	Scope
Concierge operations	Runs concierge mail + filing jobs.	Platform
Concierge attorney	Attorney review inside the concierge pipeline.	Platform
Concierge translator	Translation tasks on concierge jobs.	Platform
Concierge printing	Print + assembly on concierge jobs.	Platform
Printing lead	Oversees the printing queue.	Platform
Tenant printing	Prints, clips evidence, and mails a firm’s packet on the firm’s behalf.	Platform

The Tenant printing desk is where staff handle a firm’s print-and-mail handoff: print the packet, clip the evidence, mail it. Completing the desk task hands the case back to the firm’s pipeline, and the firm gets the usual “packet printed and mailed” email.

Platform roles (Fola-internal)

Role	What it’s for	Scope
Platform admin	Full administrative control of the platform.	Platform
Ops agent	Day-to-day operations tooling without full admin.	Platform

Custom roles

When no predefined bundle fits — say an intake specialist who adds clients and sends questionnaires but never touches billing — admins can author one. On the admin Roles page (/workspace/admin/roles, Fola-internal), New custom role takes a label, a scope (Platform or Firm), and a hand-picked permission set, and adds the role to the catalog under a generated custom.* key. From there it behaves like any other role: grant it by email, revoke individual bindings, and every change lands in the audit trail.

Custom roles can be renamed and re-bundled after creation — everyone holding one picks up the new permission set immediately. The key and scope never change once the role exists, and a custom role can only be deleted after every grant of it has been revoked. Predefined catalog roles can’t be edited or deleted from this surface.

Granting and revoking

Access is managed through two views over the same grants — pick whichever matches the question you’re asking:

By person — the Access card. On the admin user-detail page (/workspace/admin/users/{id} — Fola-internal), the Access card lists every grant the person holds (role, scope, note, granted date), grants new roles from a picker, and revokes from the same list. A compact Primary role control sits beneath it for legacy compatibility.

By role — the Roles page. At /workspace/admin/roles (Fola-internal), browse the whole catalog — each role’s permissions and member count — open a role to see everyone who holds it, add a member by email, or revoke from the role side.

Grants can expire. Any grant can carry an expiry date — set it when granting and the access disappears on schedule, no reminder needed. Handy for contractors, coverage while someone’s away, or a temporary desk assignment. An expired grant stays visible in history, marked as expired.

Every grant records who granted it, when, and the note — so “why does this person have access?” is always answerable from either view. The Roles page’s Activity view shows grants and revocations as a single feed — who granted or revoked which role, for whom, when — newest first.

Firms have their own Roles page. Firm owners and admins get Administrative → Roles in their workspace: the five firm roles, what each grants in plain language, who holds each, and inline role changes (ownership transfer stays on the Members page). Firm owners and admins can also define their own roles there — a name plus a hand-picked set of firm permissions — and grant them to members like any built-in role, optionally with an expiry date.

Groups

A group is a set of people that holds roles together. Instead of granting the same three roles to eight people one by one, grant them once to a group: add a person to the group and they immediately get every role the group holds; remove them and those roles go with them. Granting a group a new role — or revoking one — changes what every member can do at once.

Groups are managed on the admin Groups page (/workspace/admin/groups, Fola-internal): create a group, add members by email, and grant it roles from the same catalog the Roles page uses. Two rules differ from personal grants: case-scope roles can’t be given to a group (case assignments stay personal), and firm-scope roles need an explicit firm, since a group doesn’t belong to one. Deleting a group revokes everything it holds, so its members lose those roles at the same moment.

Firms get Groups too. Firm owners and admins have their own Administrative → Groups page. Firm groups are scoped to the firm: members come from the firm’s roster, and the roles a group holds are firm roles — so “everyone on the intake team gets Paralegal” is one grant, not eight.

On a person’s Access card, roles that arrive through a group appear after their direct grants, marked via the group’s name. They can’t be revoked from there — take the person out of the group (or revoke the group’s role) on the Groups page instead. Group membership changes and group grants land in the same audit trail as every other privilege change.

What this changes for firm users

Nothing day-to-day. Your role gates the same features it always did; the rebuild changes how access is granted (as auditable, scoped grants that can stack), not what each role can do.