Who can see what?

Permissions describe actions, not screens. Reading a case, updating it and deleting it are separate permissions, and so are creating an invoice and viewing one. Permissions are named by group and action, so what a role can do is written in plain terms.

These groups are examples; the current permission catalog contains more specific operations. Assigned-case reading is selected separately and does not automatically grant writes or all-branch access.

Cases

View casesCreate casesEdit casesDelete cases

Clients

View clientsAdd clientsEdit clients

Documents

View documentsUpload documentsDelete documents

Finance

View invoicesCreate invoicesView paymentsExport invoices to accounting

AI

Use AICreate drafts

Webhooks

View integrationsManage integrations

Roles

View rolesManage rolesInvite users

Catalog roles and custom roles within your authority can be used. Creating roles, assigning permissions and inviting members require separate permissions and current plan limits; a role name alone does not determine access.

The server enforces owner protection and limits on delegated permissions. When selecting assigned-case-only reading, check other roles and direct grants too: full case reading from another source broadens the scope. This selection alone does not narrow other modules. The role and permission guide provides design examples.

An invitation adds membership and a role in the selected company. A new-account invitation leads to account setup; an existing account holder signs in with the invited, confirmed email account and accepts the link. Acceptance does not change the existing profile, password or primary company, and does not switch the active company automatically. Delivery depends on the provider and a valid invitation. Added role permissions may appear on the next token refresh; permission removal and role/membership changes may require signing in again. The illustration sends or accepts no real invitation.

Illustrative role and invitation flow; creates no record or invitation

New role: Intern

• Cases
• Clients
• Documents
• Finance
• AI
• Webhooks
• Roles

Invitation

[email protected]

Example: invitation

The intern's menu

• Cases
• Clients
• Documents
• Finance
• AI
• Webhooks
• Roles

‹›

01/05

Create the role

1. 1/5

   Create the role

   Choose a sample role name; actual creation requires role-management permission.

2. 2/5

   Tick the permissions

   Select example permissions; actual assignment is checked against current authority and delegation limits.

3. 3/5

   Invite the user

   Illustrative invitation step. An existing account holder signs in with the matching confirmed account and accepts; the animation sends or accepts no real invitation.

4. 4/5

   The invitation is accepted

   A new-account invitation leads to account setup; an existing account signs in with the matching confirmed email and accepts. The animation performs no real acceptance.

5. 5/5

   The menu follows the access

   The illustrative menu narrows to the sample grants; it does not replace real server authorization.

Branch and team operations require the relevant permissions and plan scope. Teams organize members; team membership alone does not partition case data. Branch membership, cross-branch access and case assignment have their own scopes; do not assume a case is visible only to a particular team.

The company switcher moves between memberships already held by the account; it creates no membership. An existing account gains a membership after its holder signs in with the invited, confirmed email and accepts; acceptance does not switch the active company automatically. The active company and current permissions are re-evaluated when switching. The company legal department solution illustrates an organizational structure.

Company selector

• Example Law Firm
• Example Holding Legal Department

Catalog roles exist; authorized users can also define custom roles and permission sets. The five rows here are not an exact dump of default grants. Owner protection and delegation limits are enforced in real operations.

If an account already has multiple memberships, the switcher moves between them. To add a membership, the invited existing account holder signs in with the matching confirmed email and accepts; this does not switch the active company automatically. The active company and permissions are re-evaluated on switching.

Access through the removed company membership ends and account security state rotates. Another company membership may remain, but the rotation may require signing in again there too. Own-session individual/bulk revocation is also available.

Yes; company security-policy management permission is required. The user enabling the requirement must enroll their own MFA first. Unenrolled members are directed to setup before business screens; this is not an SMS-code flow.

Access follows company and branch membership, cross-branch permissions and applicable record scope. Team membership alone does not partition files. Assigned-case scope is selected separately; full case reading from another role or direct grant broadens it.

Every team is created under a branch; a team gets a name and description, and members are added to and removed from it. Viewing teams, managing them and looking up members are separate permissions. Team membership alone does not separate file access.