How to Give Clients Project Access Without Exposing Internal Work

You can give clients useful project access without exposing internal work by combining four controls: guest roles, card assignments, restricted boards and explicitly shared Drive folders. Do not rely on a board name such as “Client Portal” to create privacy. Access must be enforced through permissions.

In kloudboard, guests are free and do not count as paid seats. Owners and members count toward the potentially billable seat calculation. That makes a guest the usual starting role for a client who needs to review deliverables, comment on files or follow selected work but does not need to manage the workspace.

Map people and actions before sending invitations

Start with actions rather than job titles. Two people called “client” may need different permissions. A marketing lead might review drafts and monitor approved deliverables, while a brand asset manager might also upload logos and product files.

Create a small access matrix for every external collaborator:

“Likely setup” is a starting point, not a universal preset. Workspace presets and individual permissions can differ, so inspect the saved permissions for each person after inviting them.

Choose guest versus member based on control

Use a guest when the person should operate within a restricted slice of the workspace. A scoped guest without the “view all cards” permission sees only cards assigned to them. Card visibility is enforced server-side rather than being a cosmetic filter.

Use an owner or full member only when the person genuinely needs broader operational authority. Full members can be granted or denied individual capabilities, but owners and members are included in the potentially billable seat calculation. Guests are free.

This does not mean every external person must be a guest. An embedded client-side producer who manages the full project may need member capabilities. The tradeoff is broader responsibility and potential seat cost. Review current plan details on the kloudboard pricing page before deciding.

A roster alone cannot verify an invoice. Subscription state, historical seat changes and invoice adjustments also affect billing. For a deeper seat audit, use the process in the free client seats versus paid user seats guide.

Separate internal work with assignments and board restrictions

Assignments provide the narrowest card-level boundary. If a guest does not have “view all cards,” an unassigned card is invisible to them. Assign the client only to cards they should open.

For example, a video campaign might contain these cards:

This lets an internal team and client use the same production board without showing every card. The risk is operational: assigning the client to the wrong card exposes that card. Use clear card names and make client assignment a deliberate handoff step rather than a default automation.

Board restrictions add a wider boundary. A board can be limited to a named member list. Use this when a board is entirely internal, such as finance, staffing, talent negotiations or post-project retrospectives.

A practical structure is:

• Internal operations board: restricted to the agency team.
• Production board: shared with editors; clients see only assigned review cards.
• Client delivery board: restricted to the relevant internal team and named client contacts.

You do not need a separate client-facing board for every engagement. Use one when it reduces assignment mistakes or gives the client a clearer experience. Keep one production board when duplicating statuses and cards would create version confusion. The kloudboard boards overview provides more context on organizing the underlying workflow.

Set Drive access by required action

Board access and Drive access solve different problems. A client may have permission to open an assigned card without having general access to the folders used by the production team.

Choose Drive Viewer when the client needs to view, download and comment on files but should not upload. Viewer is not strictly read-only because comments are allowed.

Choose Drive Editor when the client must upload files directly to a shared folder. In workspace Settings > Members, select the guest, enable Drive and set Drive access to Editor. Then share the intended folder with that guest in Drive.

Both pieces matter. Sharing a folder determines which files the guest can reach; it does not upgrade Viewer access to Editor. Likewise, setting Editor access does not mean every folder is visible. Without “See all files,” guest visibility is limited to folders shared with them.

Files attached to cards are stored in the workspace Drive. Reorganizing an attached file in Drive does not break its card link. A client can also review versioned files with timestamped comments and @mentions. For a broader review process, see the video review and approval workflow guide.

Worked example: expose review work, not production notes

Assume a five-person agency is producing six videos for one client. The agency has an owner, a producer, two editors and an internal strategist. The client has an approver and an asset coordinator.

The approver needs to review six drafts, download approved versions and comment. The asset coordinator also needs to upload logos, product footage and brand documents.

1. Keep the agency owner, producer and internal team in their appropriate owner or member roles.
2. Invite both client contacts as guests without “view all cards.”
3. Restrict the internal planning board to the five agency people.
4. Keep the production board available to the production team, but assign client contacts only to the six review cards.
5. Enable Drive Viewer for the approver and share the client delivery folder.
6. Enable Drive Editor for the asset coordinator and share a separate “Client uploads” folder.
7. Attach each draft to its corresponding review card and upload revisions as new versions of the same file.

The outcome is intentionally asymmetric. The approver can see assigned review cards and comment on shared files but cannot upload into Drive. The asset coordinator can upload into the explicitly shared intake folder but does not gain access to unshared production folders. Neither client sees unassigned cards or the restricted internal board.

The main tradeoff is administration. Fine-grained access reduces exposure, but someone must maintain assignments and folder sharing. If the client needs access to almost every deliverable, a dedicated client delivery board may be easier to operate than dozens of individual assignment decisions.

Verify the boundary before adding real work

Run the test with harmless placeholders. Create one assigned card called “Client test — visible” and one unassigned card called “Internal test — hidden.” Put them on the relevant board and confirm the client can open only the assigned card.

Next, create a shared test folder and an unshared test folder. Confirm that the client can reach only the shared folder. If the person has Viewer access, verify that viewing, downloading and commenting work while uploading does not. If the person has Editor access, upload a disposable text file to confirm the intended folder accepts it.

Finally, inspect board restrictions and the person’s saved permission toggles in workspace Settings > Members. A successful login is not an access test. Verification means proving both sides of the boundary: required work is visible, while at least one representative internal card, board and folder remains inaccessible.

Once the test passes, replace the placeholders with the first real review card. Keep the access matrix with your project setup notes so the next producer knows why each client has Viewer, Editor or assignment-only access.