The client portal is a hardened, client-facing surface that shows only what you choose to share. It is the place your client lands when you send them a link: a clean, branded space where they read what you sent, fill in the form you asked for, sign where needed, and upload the documents you requested. Everything they do flows straight back into the matter.
Nothing else in your workspace is visible. A client sees the portal you built for them and nothing beyond it. There is no browsing, no guessing at other links, no way to reach a neighbour’s matter. The portal is the entire world your client can touch, and you decide exactly what is in it.
What it does
A portal is a curated window onto a single client’s work.
-
You share exactly what you mean to share. You attach specific objects - a matter, a form, a file, a request - to the portal one at a time. Each attached object is on the allow-list. Anything not attached simply does not exist as far as the client is concerned: it is denied by absence, not hidden behind a setting that could be flipped by accident.
-
The client views, responds, signs, and uploads. Inside the portal the client reads what you shared, completes the to-dos you assigned, submits forms, and uploads documents. A submitted form moves the matter forward. An uploaded file lands as an encrypted record. A completed step is marked done and timestamped. You see all of it, with a full activity trail.
-
One client can never see another client’s portal. This is the anti-enumeration fence. Each client holds a token scoped to their portal alone. There is no shared index they can page through, no sequential IDs to walk, and rate limits sit on every guessable surface. A request for something that is not theirs returns the same answer as a request for something that does not exist, so a portal cannot even be probed for whether it exists.
-
It carries your brand. Logo, colours, a public name, and a contact route. To your client it looks like your firm’s own front door, not a generic tool.
How you use it
The flow is the same every time, whether you are onboarding one client or running a hundred matters in parallel.
-
Build the portal. Create a portal from a template, which pins a known-good configuration and sets the branding and layout. This is your staging area: you assemble it before anyone outside ever sees it.
-
Share the objects you want the client to act on. Attach the matter, the forms, the files, and the requests. For each one you choose how much is visible - full detail, a read-only view, hidden fields, or whether the client can write back. You can preview the result exactly as the client will see it before any link goes out.
-
Send the link. Add a named recipient by email, which mints them a personal access link. The link starts inactive and binds to the first person who claims it, so a forwarded link cannot be picked up by someone it was not meant for.
-
The client acts. They open the portal, work through what you assigned, and respond. If they need something that is not yet shared, they can request access - which lands as a request for you to approve, never as the portal quietly widening itself.
-
It flows back to the matter. Every response, signature, form, and upload writes into the matter and onto the audit record. Your staff see it in real time. There is no re-keying and no separate inbox to reconcile.
When you are done, you can suspend a portal to pause access, reactivate it later, or archive it to end access for good while keeping the full record. A scope-wide kill switch invalidates every outstanding link in one call if you ever need it.
The kernel verbs behind it
Every action in the portal is a single kernel verb. The same verbs power the builder you use, the link you send, and the read your client performs - one set of rules, permission-checked and audited every time.
portal.create- instantiate a new portal from a template version, ready for you to fill.portal.object.attach- add a matter, form, file, or request to the portal’s allow-list. Anything not attached is denied.portal.set-visibility- choose how much of an attached object the client sees: full, read-only, hidden fields, or write-back.portal.link.add- add a named recipient by email and mint their personal access link.portal.link.activate- bind a link to the first person who claims it, so exactly one holder wins.portal.session.start- the client’s authenticated entry into their portal.portal.traverse- the bounded, deny-by-default read the client uses to walk only what was shared, the same path that powers your preview.portal.task.complete- the client submits a form, signs a step, or uploads a document, flowing it back to the matter.portal.request-access- the client asks for something not yet shared; it lands as a request for you to approve, never a self-widening.portal.bump-access-version- the scope-wide kill switch that invalidates every outstanding link at once.portal.archive- end all external access for good while keeping the record and the audit chain.
See the full set in the portal verb reference.
Who your clients are
Clients are external users. They never hold a staff account, and they never see your workspace. Each one carries a token scoped to a single portal: it is the only thing that token can open, and it stops working the moment you revoke it, suspend the portal, or bump the access version. The read a client performs resolves only their own allow-list, so the portal is a one-way window - your client looks in at exactly what you shared, and can see nothing around it.
For how the token boundary, the external tier, and the deny-by-default fence fit together, see Security.