How to set up a client project portal that shows only their work

A client project portal is not a page you switch on. It is four permission surfaces that have to agree: who is in the workspace, which cards they can see, which boards they can open, and which Drive folders they reach. Get three of the four right and the fourth exposes something — usually another client's work in progress.

This is the configuration sequence for running client portals inside a single workspace, using guest accounts and card-level visibility. It assumes you already have the client's project on a board and at least one deliverable file attached to a card. If you are still deciding whether to run one workspace or one per client, settle that first — the setup below assumes one workspace with isolated boards.

A client portal is four permission surfaces, not a page

When a client says "can I just see where things are," they are asking for a combination of four separate settings:

• Membership tier. Are they a full member or a guest? Guests are free and do not count as paid seats; members do.
• Card visibility. Card visibility is enforced server-side. Owners and members with the "view all cards" permission see every card. A guest without it sees only the cards they are assigned to.
• Board access. Boards can be restricted to a member list. This is a board-level gate that sits on top of card visibility.
• Drive access. Which folders are shared with them, and whether their Drive access is Viewer (view, download, add comments) or Editor (upload).

A fifth thing — review access — rides on the file itself. Review sits beside an attached media file or PDF on a board card, with timestamped comments and @mentions on videos and documents. It does not need its own permission setting, but it does need the client to be able to see the card the file is attached to.

The three access tiers and what each one exposes

Most portal leaks come from picking the wrong row here, so compare them against your actual board structure before you invite anyone.

The bottom row is the client tier you want. Note that "guest" alone is not enough — a guest who still has view-all on sees every card on any board they can open. The tier and the permission are two separate switches.

Configuration, in order

The sequence matters because each step narrows what the next one can expose.

1. Invite the client as a guest, with view-all off

1. Invite from Settings > Team. The invitee gets an email link and lands in the workspace after signing up.
2. In Settings > Team, pick the person and adjust their individual permission toggles. Confirm the "view all cards" permission is off for them specifically.
3. Do not assume the built-in Guest preset matches what you want. The built-in Guest preset leaves the Drive page disabled, and workspace presets and individual permissions can differ from workspace to workspace — check the saved settings on the person's row rather than trusting the preset name.

2. Restrict the board to a client-specific member list

Board access is configured from the board's own settings, not the member's. Add the client and the internal people who work on that account, and nobody else.

This is the step that makes one workspace safe with several clients. If Northwind's board is restricted to the Northwind guest plus your two editors, a Meridian client cannot open it at all, regardless of card assignments. If instead you run every client on one shared board, card visibility is your only defence — and a guest without view-all will see nothing except the handful of cards you assign them, which is workable but makes the board nearly useless to them as a status view.

3. Share one scoped Drive folder

Create a folder per client, then share that folder with that guest. Two rules to keep straight:

• Without "See all files," a guest's Drive visibility is limited to the folders shared with them. Sharing a folder changes which files they can reach; it does not upgrade their role.
• Viewer access permits viewing, downloading and adding comments, but not uploading. If the client needs to drop reference footage in, enable the Drive page for them and set Drive access to Editor, then share the intended folder. Enabling Drive and choosing Editor grants the documented upload capabilities, subject to folder access.

Remember that files attached to a card are stored in the workspace Drive. A draft an editor uploads to a card lives in Drive too, and it can be reorganised there without breaking the card link. That is convenient, but it also means an internal file attached to a card the client can see is visible to the client — folder location does not hide it.

If your editors and clients overlap, the folder-scoping logic is the same one described in sharing files with freelance editors without giving full Drive access.

4. Decide who reviews which version

Review is opened from the board card, using the Review action beside its attached media file or PDF. Comments are timestamped and support @mentions. Files keep version history: uploading a new version to the same file preserves the old ones, and reviewers can switch between versions.

Because versions are preserved, an approval is only meaningful if it names one. Before the client's first review round, tell them the convention out loud: feedback is left on the current version; a new upload is a new version; sign-off names the version it approves. Without that, "the cut looks good" becomes ambiguous the moment you upload v4. The mechanics of binding comments to versions are covered in creative approval workflow with file version history, and the review tool itself in how to use Review.

Client portal configuration checklist

Run this before inviting a client, so their first login shows their work and nothing else.

Verify with a test card before the client logs in

The reliable check is the assignment list. An unassigned card is invisible to a scoped guest — so, on the client's board, create one card named something like INTERNAL — do not assign and leave it unassigned. Then:

• Confirm every card you want the client to see has them assigned. Status cards, review cards and delivery cards each need their own assignment; visibility does not inherit from a parent or a label.
• Confirm internal-only cards on the same board — the b-roll pass, the unpaid invoice note, the rough cut you have not shown yet — are assigned to internal people only.
• On the client's first login, ask them to confirm they can see the review card and cannot see the internal one. It takes two minutes and it is the only check that tests the real account rather than your reading of the settings.

If you are running several client accounts, this per-person verification is the same discipline as giving clients project access without exposing internal work, applied one account at a time.

The misconfiguration that exposes other clients

Three versions of the same mistake, in rough order of how often they happen:

1. View-all left on for a guest. Easy to miss, because the person is correctly on the guest tier and you assume that is the whole job. It is not: the permission switch is separate, and it is the one that leaks.
2. One shared board for all clients, unrestricted. Card visibility then has to carry the entire load. It will hold — a scoped guest only sees assigned cards — but any card you assign to the wrong person is instantly visible to them.
3. An internal file attached to a client-visible card. Drive folder permissions do not override a card attachment. Attach internal files to internal cards.

What you get for this effort is a client who can log in, see their review card, watch the current version, leave timestamped comments and know exactly what they are waiting on — without you maintaining a separate portal product or forwarding files by email. The broader comparison of dedicated tools versus a configured workspace is in best client portal software for agencies, but for most teams under a few dozen clients the configuration above is the cheaper path.

What to do after the first client is set up

Run the same sequence for the second client before you announce anything. If the second client's board restriction, folder share and permissions take more than a few minutes to mirror, the problem is your board structure, not the client.

Two things stay manual and are worth admitting up front: assigning new client-facing cards to the guest as the project progresses, and keeping internal attachments off client-visible cards. Neither is automated by a permission setting. Reviewing the assignment list at the start of each review round is the cheap habit that keeps them true. The client portal overview covers what the client experience looks like from their side once this is configured.