Team roles, seats, and the client portal

The team workspace is available on Pro and Enterprise. Members are invited by email, and each one holds one of three roles. Paralegals can upload and label evidence, and that is the whole permission set: a paralegal can build the exhibit record on a matter but cannot start a job, create or edit matters, or change firm settings. Attorneys can do everything a paralegal can, plus create and manage matters, submit full draft jobs, and submit RFE and RFR response jobs; this is the working role for most of a firm. Admins hold every permission, including inviting and removing members, changing firm settings, and billing. Settings that affect the whole firm are admin-only by design: the prompt library, letterhead, notification configuration, SSO, and storage settings all sit behind that role. When someone hits a wall, the message tells them the action needs a different permission; the usual fix is that a paralegal is trying to run a job, which an attorney or admin needs to do.

Seats are managed from the team panel. Invites stay pending until redeemed, and an admin can revoke a pending invite or remove an existing member. On Pro, seats do double duty: each additional seat you purchase also raises your monthly draft job allowance, so growing the team grows your capacity rather than just your headcount. Invite people at the lowest role that lets them do their job, then raise it if needed. Removing a member does not touch the matters they created or the deliverables already produced. The role model is cumulative rather than parallel: everything a paralegal can do, an attorney can do, and everything an attorney can do, an admin can do. There is no role that can run jobs but not touch evidence. If your firm has one person doing everything, admin is the right role and you can ignore the rest of team permissions until you add your second user.

Client access works differently and is a separate, Enterprise-only feature: the client portal, enabled per matter rather than firm-wide. It gives your client an invite-only page for that one matter, with a checklist, a place to upload documents, and a status line you control. Enable the portal on the matter first, then invite. Invitations go out by email with a redemption link, and each invitee gets their own; you can revoke an invite at any time, which cuts off that person's access without affecting the others.

The checklist is yours to write. Add an item for each document or task you are waiting on, and the client sees the list on their side. When they upload something, it arrives against the matter and shows up in your workspace. There is also a reminder action that emails invitees when you want to nudge without composing a message yourself. The status line is counsel-set: a short piece of text you write, shown to everyone with portal access, and Petria will email invitees when you update it. Nothing about job progress, drafting, or deliverables is exposed automatically; if the client is going to be told something, you type it.

What clients cannot see is as important as what they can: no drafts, no deliverables, no verification or gap reports; no drafting tools and no way to start a job; no visibility into other matters, including other matters for the same client; no firm settings, quota, or team information. Uploads that arrive through the portal still need your handling: give them a proper exhibit label and description in evidence before you run a job, the same as anything you uploaded yourself, because clean labels are what keep citations and verification readable.

Portal activity is recorded in your audit log, including invites, revocations, checklist changes, configuration changes, client sign-ins, and client uploads, giving you a record of what the client was asked for and when they responded. Turn the portal off on a matter when the case closes; revoking outstanding invites is the cleaner move if you want to keep the matter's portal configuration for reference.