Team Management: Invites, Roles and Reports-To

The team console is where a firm composes its practice: who is in the tenant, what each person may do, who they report to, and how the seat budget is being spent. Everything on this page is a Firm Admin or Partner action — the console is role-restricted on the server, not just hidden in the sidebar.

The console and its plan boundary

Plan feature: This capability requires the user_management plan feature (see Plan Features).

The console sits in the Administration group of the sidebar and shows three things at a glance:

• The roster — every member of the tenant (active and inactive), each with role, reports-to and state, plus the pending invitations that have not been accepted yet.
• The seat position — active users against the tenant’s max_team_seats budget. Invites that would put the firm over budget are refused, not queued.
• The pending invitations — invited-but-not-joined users, each revocable before it is claimed.

Inviting a member

The invite flow is token-based end to end:

1. Invite. A Partner or Firm Admin adds an email and a role. Which roles they may offer is set by the firm, not by the inviter’s own tier: the tenant carries a role scope, chosen by the platform superadmin when the firm is provisioned, and it is one of PARTNER_ONLY (Partners only), PARTNER_MANAGER (Partners and Managers) or PARTNER_MANAGER_ANALYST (all three, the default). A Partner and a Firm Admin are both bound by that scope. Firm Admin itself is never in it — that account is created at provisioning — and there is no Superadmin in the assignable set, since that role is platform-level, outside any firm’s roster.
2. The invitation link. The invite carries a single-use token. Accepting the link is the claim-account flow: the token is validated (the page shows the invited email and the firm name), the invitee sets their name and password, accepts the terms, and the account is activated with the invited role and tenant. The first session has no MFA gate yet; a mandated role (Firm Admin, and any role the firm mandates) is pushed through MFA enrolment at the next sign-in.
3. Before acceptance, the invite can be withdrawn or re-sent. Revoking a pending invitation is a soft delete with its own access-log entry; the seat is freed and the email can be re-invited. Re-sending rotates the claim token — earlier links stop validating at once — and an invitation that has expired gets a fresh 72-hour window.

Two guards apply at invite time: the seat budget (active users must stay under the tenant’s maximum) and duplicate-pending detection (one outstanding invite per email).

Roles and who may assign them

Role assignment sits with the Partner and Firm Admin tiers: invited members are created with a role, and roles can be changed later without re-inviting — both within the firm’s role scope, and a Partner may manage a peer Partner. The hierarchy the console manages:

Role	Scope	Day to day
Analyst	Study execution	Creates and configures studies, uploads data, works the comparables grid (accept/reject/flag/override with rationale), addresses rejections and failed runs, re-submits
Manager	Review	Reviews studies in the In Review state: approves (advancing to report generation) or rejects with reasons
Partner	Sign-off	Approves the generated document, signs the study off, archives it, generates the on-demand final document
Firm Admin	The firm	Team management, firm settings, billing and usage, security configuration; acts across study states as the firm’s operator

The Superadmin row of the platform sits outside this table — see roles and permissions for the complete hierarchy, the study transition map, and the MFA mandates per role.

Rules the console enforces:

• A user cannot change their own role.
• A role outside the firm’s role scope cannot be assigned, and neither Firm Admin nor Superadmin is ever assignable from the console.
• A user can only act on members whose role is inside that same scope — an actor outside it gets an explicit refusal.
• Role changes apply going forward; actions already taken stand under the role they were taken under.

Reports-to chains

Each member can carry a supervisor, and the chain is validated strictly:

• Analyst → Manager only.
• Manager → Partner only.
• Partner and Firm Admin → no supervisor.
• No self-supervision, no loops. A member cannot report to themselves, and the chain is walked upwards at save time so a proposed supervisor who already reports (however indirectly) back to the member is refused. An inactive user cannot be assigned as a supervisor.

The chain is not decorative: review routing follows it. The study an analyst submits lands in the review queue of the manager it reports to, and the sign-off gate belongs to the Partner tier. Set the chain before the first submission, or the queue behaves as if the work had no owner. See workflow configuration for how the states and the routing fit together.

Removing a member

Removal deactivates the account (it is not a hard delete), and the guard rails are explicit:

• You cannot remove yourself.
• The last Partner in a tenant cannot be removed.
• You can only remove a member whose role sits inside your firm’s role scope.
• The member stops being able to sign in immediately: every API call authenticates the acting user, and removal rotates the account’s token version, so sessions minted before it are dead and cannot be revived by a later reactivation.
• Reactivation is a separate action. Deactivating is reversible for anyone but yourself — the same scope rules apply, and the re-enabled account picks up the same tenant, role and record.

What happens to the member’s studies:

• Studies are tenant records, not personal files. The study list, the states, the comparables, the statistics and the full audit trail are untouched by the removal.
• Work in review is role-owned. A study sitting in In Review is the reviewer’s to approve or send back regardless of who built it; the queue does not orphan when the builder leaves.
• Drafts and failed runs need an owner. A draft was being prepared by its analyst; if that analyst is removed mid-preparation, reassign the work to an active analyst (a Firm Admin can re-drive a failed run or cancel a stalled one). Remove members around the work, not through it.

FAQ

Can I remove the last Partner? No — the console refuses it. Add or promote another Partner first.

Does removal delete the member’s studies or audit history? No. Studies are tenant records and the audit trail is an immutable firm record; removal only deactivates the account.

Who decides which roles we can invite? The firm’s role scope, not the inviter’s tier — a Partner and a Firm Admin have the same rights inside it. If the console refuses a role you expected to offer, the scope is the reason, and only the platform superadmin can change it (Add Firms console). The default scope covers Analyst, Manager and Partner.

Can we change a Firm Admin’s role from the console? No. Firm Admin is created at provisioning and is outside the assignable set; the same goes for the platform Superadmin role.