How to Give Freelance Editors Access to Only Their Assigned Projects

To scope a freelance editor to only their assigned work in kloudboard, do three things: invite them as a guest, leave their view all cards capability off, and assign them only to the cards they need. Card visibility is enforced server-side, so an unassigned card is genuinely invisible to a scoped guest rather than hidden in the interface. Board member lists and shared Drive folders add the second and third layers.

Two details shape the setup. First, a workspace is the shared home for one team, and boards, chat, Drive, Brain and economy are all workspace-scoped. Second, scoping happens at the card, board and folder level, not at a named "project" object. That means the way you split work up before inviting anyone matters more than the permission toggles you click afterward.

Decide the structure before you send an invitation

If you run several clients in one workspace, you can keep a freelancer contained with card assignments and restricted boards. If the clients are genuinely confidential from each other, a workspace per client is the harder boundary and worth the extra admin. Pick one deliberately; retrofitting later means re-inviting people and rebuilding shares.

Worked example: two editors, three clients

An agency runs one workspace with three clients: Northline (a YouTube channel), Kite & Co (a retainer), and internal work. The team is one owner, one staff producer called Sam, and two freelance editors. Maya edits Northline and Kite. Dev edits Kite only, and Kite's client has asked that nobody outside the account touches their assets.

On seat counts, the current roster contains one owner and one member, so two potentially billable seats, with the two guests free. That does not verify the invoice. Roster quantity alone never proves a charge is correct, because invoice adjustments, subscription state and historical seat changes also matter. Check the actual subscription and seat record in Settings > Billing if the numbers look wrong, and do not remove a guest expecting a bill reduction: guests are free and do not count as paid seats.

Maya's arrangement is the realistic compromise case. She is inside the workspace, so her scoping only holds if her assignments stay current. If Northline and Kite are never supposed to see each other's material, splitting them into separate workspaces removes that ongoing risk.

Set it up in this order

1. Invite as a guest. Use Settings > Team or the Invite button. The invitee gets an email link and lands in the workspace after signing up. Guests are a restricted tier; full members can be granted or denied capabilities individually, guests cannot be promoted one toggle at a time.
2. Open the person's permission profile and turn off view all cards. Keep them on the guest tier without that capability. This is the single control that decides whether they see every card or only their own.
3. Decide Drive access from the task, not the job title. The built-in Guest preset leaves the Drive page disabled, and the guest tier does not automatically grant Viewer access. Workspace presets and individual permissions can differ, so check the saved settings rather than assuming.
4. Share only the folders they need. Sharing a folder changes which files a guest can reach. It does not upgrade Viewer to Editor, so it cannot grant upload permission on its own.
5. Restrict sensitive boards to a member list from the board's settings. This is your second layer for work that should not appear to a scoped guest even if someone assigns the wrong card.
6. Assign cards last, once the boundaries exist. Assigning first and restricting afterward leaves a window where the wrong work is visible.

For the file-sharing mechanics, the step-by-step companion guide on sharing files with freelance editors without full Drive access covers folder setup and the Viewer versus Editor decision. If you are also onboarding client-side reviewers, the same controls are covered from that angle in giving clients project access without exposing internal work.

Drive access: pick the level by required action

Files attached to a card are stored in the workspace Drive, so an editor's upload can be reorganized in Drive without breaking the card link. Uploading a new version to the same file preserves the earlier ones, and reviewers can switch between versions. Timestamped comments and @mentions work on videos and documents, which is usually the reason to keep review attached to one versioned file rather than a chat thread.

Verify before real client work lands

Create two throwaway cards in a board the editor is expected to work in: one assigned to them, one assigned to nobody, with an obvious name like "ACCESS TEST — should be invisible." Then confirm from their side that the assigned card appears and the unassigned one does not. An unassigned card is invisible to a scoped guest by design, so if it shows up, their view-all setting or their role is wrong.

Run the same test on storage: share one folder, leave a second folder unshared, and ask them to open both. Then check a board that is restricted to a member list and confirm it is either visible or absent, whichever you intended. Do this with placeholder content, not a live client cut.

Common failure cases and their fixes:

• Editor sees every client's cards. Their view-all cards capability is on, or they were invited as a member. Fix the permission profile at the person level in Settings > Team.
• Editor can see cards but cannot upload. The Drive page is disabled for them, their Drive access is Viewer, or the target folder was never shared. Sharing alone will not grant uploads.
• Editor cannot find a file they were told about. Without See all files, guest Drive visibility is limited to shared folders plus their assigned-card attachments.
• A restricted board disappeared for a staff member. Board restriction uses an explicit member list; add anyone who needs it rather than relying on their workspace role.

Offboarding at the end of a project

Assignments, board membership and folder shares are three separate grants, and revoking one does not revoke the others. When an editor's run on a client ends:

• Remove their assignments from that client's cards. A guest with no assignments sees nothing at card level.
• Remove them from any board restricted to a member list for that client.
• Remove their folder shares, or move the folder so it is no longer shared with them. If they still work on other clients, keep the pieces those clients depend on.
• Check whether they should stay in the workspace at all. Removing a guest from the roster is an access decision, not a billing one.
• Write down what you revoked and when. The next producer inheriting the client should not have to guess why someone still has a folder.

The setup is correct when the test card stays invisible, the unshared folder stays closed and the restricted board is reachable only by the people on its list. Keep the access matrix — who is a guest, what they are assigned to, which folders they touch — with the project's setup notes. That document, not the permission screen, is what makes the next onboarding fast. For the wider roster and cost context, see free client seats versus paid user seats and the current pricing page.