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.
Teammates work in the dashboard. Clients work in the portal at /portal. The same email address can be a teammate in one workspace and a client in another.
Signing in and navigating
You add a client using Add client from the Case actions menu. This sends a real email directly to the client via SendGrid. Your own Gmail is never involved. The client clicks the link and opens the portal by signing in with Google using that exact email address.
When a client has shared cases across multiple workspaces, they see a Select Workspace picker. The home page then lists the selected workspace's cases and includes a Search cases... field. Each case card shows a portal display ID, a subtitle, and tags. The portal header includes a Sign out control.
What a client can see
A client never sees the dashboard or other clients' cases. Workspace isolation, category visibility, and form exposure are enforced server-side. A client cannot bypass these rules by changing a URL.
A client sees only case fields their access allows. Fields default to hidden unless explicitly made visible.
The Documents console shows files only if you turn on Expose files when adding the client. When exposed, the list filters files to the client's visible categories. The portal case surface includes a calendar. The Activity timeline hides entries about files the client cannot see: every file entry when files are not exposed, and entries about files in categories outside the client's visible set. A client can write a note in the portal if you grant permission, though this defaults to false. Portal notes are text only.
Managing client access
The Team view sets the Clients baseline visibility for everyone in the workspace. You change a specific client's access by clicking their avatar inside a case and choosing Edit visibility. This lets you widen or narrow their scope.
You remove a client entirely using Remove from case. Client removal is permanent. It revokes access immediately on their next request. Unchecking a category also revokes that file access immediately.
Forms to fill
A form is a template built with Form field inputs and no document. You assign forms using the Forms to fill (optional) picker when adding a client. Forms selected at invite time appear in the email. You expose forms later by clicking the client's avatar and choosing Manage forms. This sends no extra email.
A form must belong to the case's workspace. The portal does not show, open, sign or accept a form from another workspace, even one exposed before this check existed.
The Forms to fill section renders when you expose at least one form. Unsubmitted cards show an Open or Review & sign action. Clicking Open expands the form inline. The form presents only question inputs with labels, placeholders, help text, and required states. Extracted and static fields never appear.
Required questions are marked. The server prevents submission until they are answered. Answers prefill from visible case values. A question keyed to a hidden field starts blank. Clicking Cancel discards answers without saving.
Form submissions
Two clients can submit the same form. The later answers overwrite the shared case fields.
Submitting a form updates the case fields. Blank answers are skipped. They never erase a case value. A submitted card flips to Submitted and shows a Done pill. The portal disables the card for that client. There is no auto-saved draft. There is no portal-side edit after submission.
A form submission logs an entry on the Activity timeline attributed to the client's email. The timeline reads Filled plus the form name and includes an expandable View N answers list. The case team receives an in-app bell notification. The app dispatches notification emails based on recipient preferences.
A teammate corrects any mistakes by editing the case fields directly. The original submission remains on the timeline.
Electronic signatures
A single-source template with signature fields appears as a Review & sign action. A multi-source document cannot be signed in the portal. It falls back to a standard form and displays This document must be signed by your contact.
Signing requires a portal-authenticated collaborator. Document Blueprint does not offer public signing links. The signing flow lets the client answer questions and adopt a signature.
Every required signature spot must be signed. Missing or invalid signature images, extra spots, and incorrect page references are rejected before the document is saved. The server automatically fills any date-signed fields.
On submission, the server renders and stamps the final PDF. It saves the file to the case Documents. The portal displays Document signed and The signed PDF has been added to this case's Documents.
The app records the signer identity, time, consent, and tamper-evident hashes. The timeline records a row reading Signed {document} · N electronic signatures.
This provides an electronic signature under the ESIGN/UETA model. It is not notarized and it is not a cryptographic-PKI signature. Legal sufficiency is a customer determination.