Client service breaks down when the shared view is assembled from email threads, file links, billing systems and private working notes. The real problem is not another place to upload files. It is deciding exactly what crosses the client boundary, when, and with what evidence.
ClientPortal gives each client a branded workspace tied to their matters. Internal teams retain the operational view; clients see only active work and published material for which they hold current scope.
One front door, a hard boundary
Workspace membership is not blanket access. Every client must be active, unexpired and explicitly assigned to a matter. A suspended workspace closes the whole boundary immediately. The application can switch between internal and client perspectives, making that boundary visible during ordinary work and review.
Sharing should be an intentional publication event, not a side effect of knowing a URL.
Publication is deliberate
Updates begin as internal drafts, enter review and can publish only when an eligible client audience exists. Withdrawal removes the client view without erasing the record. The internal team retains who wrote, reviewed, published and withdrew the update, alongside the material itself.
Scoped
Workspace, member and matter checks are applied together on every client request.
Explicit
Nothing becomes client-visible merely because it exists in the workspace.
Durable
Submissions, access events and decisions remain intact across later changes.
Access belongs to a version
A document grant names the exact version, member or audience, permission and expiry. Uploading a new version does not silently carry old access forward unless the document is explicitly configured to inherit publication. Download tokens are short-lived, single-use and bound to the same member, version and permission as the grant.
Create the matter, draft the update and upload a version without exposing it.
Assign active client members and grant access to an exact file version.
Release reviewed content only when an eligible audience exists.
Record views, downloads, submissions, decisions and later withdrawals.
A decision keeps its context
Tasks preserve every client submission and each acceptance or reopen note. Approval requests offer bounded options and pin the supporting-material version. Once decided, the actor, option, note and material version are immutable, so a later file upload cannot rewrite what the client approved.
How it is built
ClientPortal uses the System32 house stack: a Go API with SQLite and a Next.js 16 / React 19 interface. Its demo environment contains twelve workspaces, 90 members, 64 matters, 140 updates, 420 documents with 680 versions, 190 tasks, 110 invoices, 48 approvals and more than 1,000 access events. Tests cover hidden matters and drafts, revoked and expired access, token binding, audience requirements, version-grant inheritance, task history, approval immutability, withdrawal and workspace suspension.
ClientPortal is available now in the System32 catalog. Switch from the internal view to a client perspective and follow the same matter across updates, documents, tasks and approvals.