The client portal
The portal at /portal is where Clients sign in to see the cases shared with them, scoped to granted file categories, where they fill exposed forms and electronically sign documents.
Workers stay in the dashboard at /; Clients live in the portal at /portal. The two never redirect into each other, and the same email can be a Worker in one workspace and a Client in another (independent seats). The portal shares dashboard code but locks down at the data layer: category visibility, form exposure, and workspace isolation are enforced server-side, so a client can't escalate by URL-tricking.
What the portal shows
A Client must be added to a case via that case's Clients panel (send templates do not add clients). On sign-in the home page lists every granted case (card = name plus identifier). Opening a case shows only: the case fields their scope allows (fields default to hidden from clients unless explicitly made visible, per collaborator scope); the Files list filtered to granted categories; the Activity timeline with hidden-file entries removed; and a Forms to fill section. No dashboard, no other workspaces, no other clients' cases. One visible-categories list per share drives files, timeline, inbox chips, and AI chat results, with no per-field toggles.
Forms to fill
A form is any template with Question value-source inputs, exposed per client per case: at add time via the optional Forms to fill picker (ticked forms are named in the invite email), or later via Manage forms in the client's ⋯ menu (appears on next load; no extra email). The section only renders when at least one form is exposed to this client on this case.
Each card shows the form name and a status: Open or Submitted. Open expands the form inline (no separate page); Cancel backs out without saving. It presents only question inputs (label, placeholder, help text, required flag); extracted and static fields never appear. Required questions are marked and won't submit until answered, a rule the server enforces too. Answers pre-fill from case values the client may see; a question keyed to a hidden field starts blank.
On Submit, three things happen atomically: each answer writes back to its keyed case field (blanks skipped, never erasing a value); a form_submission entry lands on the timeline attributed to the client's email, reading "Filled" plus the form name with an expandable View N answers list (each updated field's provenance links back to this entry); and the case team gets an in-app bell notification (no email for submissions).
Documents that need signing (Review & sign)
When the exposed template has signature fields and renders from a single document source, the card reads Review & sign:
On submit, the server stamps the final PDF, saves it to the case's Documents, and records who signed, when, the consent agreed to, and tamper-evident hashes of the signed file. The timeline shows "Signed · N electronic signatures" instead of a form_submission row. This is an electronic signature under the ESIGN/UETA model (consent, intent, identity, audit trail), not a notarized or cryptographic-PKI signature; legal sufficiency is the customer's determination. A signature document with multiple sources can't be signed in the portal yet: the client sees "This document must be signed by your contact" and it's handled outside the portal.
Signing in as a Client
The invite is a real email sent directly via SendGrid when a member adds you as a case collaborator, separate from the member's own Gmail (their Gmail is never involved). Click the link and sign in with the email that received it; the home page then shows every shared case. From there, open a case, or pick a form from Forms to fill to start a submission, or pick a Review & sign document to electronically sign it.
Troubleshooting
Client can't sign in. Check the exact email used when adding them; sign-in matches by email.
Client sees files you didn't intend. Open their row in the Clients panel, pick Edit visibility, and uncheck categories. Removing a client or unchecking a category revokes access immediately on their next request (no soft-delete).