How to Give Clients Access to a Project Without Sharing the Whole Workspace

Clients need to see the work you are doing for them. They do not need every other project, every internal argument, or the names of your other clients. The safe pattern is a limited member plus a share on one project, one section, or one task.

That pattern is not a client portal. A portal is a separate site, often with its own pages for files and approvals, sometimes with no real account inside your workspace. What follows is access inside the project tool, narrowed on purpose.

Why a full workspace invite fails

A workspace is the container for many projects. A normal member with a broad role can open what that role allows across the workspace. If you invite a client “so they can follow along,” you have often given them the same front door as your staff.

The failure shows up in ordinary ways:

• They open a project that belongs to another client because it was in the same list.
• They read a comment that was meant for the producer, not the buyer.
• They edit a date because the role allowed edit, and you only wanted them to look.

Fix the invitation, not the client’s manners. Decide the object they may open, and the level, before you send the invite.

Limited member, then a share

Two steps, in order.

1. Invite them as a member on a role that can do very little. A guest, in this model, is not a separate kind of account. It is a workspace member whose role has few or no general permissions. They should not be able to create projects, browse every task, or manage members. The role is what keeps the rest of the workspace closed.

2. Share one item with a level. The item is a project, a section, or a task. The level is view, comment, or edit.

Level	They can	They should not
View	Open that item and read it	Change tasks or carry on a working discussion if comment is a separate right
Comment	Discuss that item	Change dates, assignees, or status, if edit is what those changes require
Edit	Change the shared item within the product’s edit rules	See projects you did not share

Share the smallest object that answers their question. A client who only approves the homepage does not need the whole project. A client who is waiting on five deliverables may need the project, still at view or comment, not edit.

Someone has to hold the permission to manage shares. Do not leave sharing to whoever has the client’s email address and an admin role they use for everything.

What to leave internal

Before you share, look at the project the way the client will see it.

• Internal notes about budget arguments, staffing, or other clients stay off the shared task. Put them on a task you do not share, or in a channel the client is not in.
• Draft comments you would not say in a meeting do not go on a shared task. Comment access means they can read that thread.
• Status names that only make sense internally (“waiting on us to stop arguing”) confuse a client and leak tone. Use statuses you would say out loud.

A view share is still a disclosure. If the task description contains the internal cost, they can read the cost. Move that detail before you grant view.

How this differs from a portal

People ask for a client portal when they want a clean page: status, files, and a place to approve, without the feeling of logging into the team’s tool. That is a fair request. It is a different product shape.

A limited member with a share still logs into the project workspace, then sees the item you granted. There is no separate portal home, no anonymous link that works without an account, and no invoice attached to the share. If you need a branded approval site, you are shopping for something else. If you need the client to follow one project without seeing the others, a guest role plus a share is the fit.

Do not describe the share as a portal in a proposal. The client will expect a portal, then land in a task list.

Two client situations

A retailer wants a weekly look at a packaging redesign. They should comment, not edit. You invite their brand manager on a reviewer role and share the packaging project at comment. They can discuss the dieline task. They cannot open the staffing project in the same workspace, because the role cannot view all projects and you did not share that project.

A freelance copywriter must rewrite three product pages and does not work for the client. Edit on those three tasks, or on the section that holds them, is enough. Edit on the whole project lets them change dates on work they were not hired for. The smaller share is the better one. When the pages are approved, remove the share. Leaving edit in place “in case they come back” is how last year’s contractor still has access in March.

In both cases you tell the person what the invite is. The brand manager is not receiving a portal login. The freelancer is not receiving the studio’s workspace. If either description is what you already promised in email, correct the email before you send the invite.

A practical sequence

1. Create a role that cannot manage the workspace and cannot see every project. Name it so the next person understands it, for example “Client reviewer.”
2. Invite the client onto that role.
3. Share the project, or only the section or task, at view or comment.
4. Open a task they can see and read it as if you were them. Remove anything internal.
5. Tell them what they can do: look, comment, or edit. Tell them what they will not see.
6. When the project ends, remove the share or the membership. Access is not a souvenir.

If a contractor must update tasks on one section, use edit on that section and keep the rest of the workspace off their role. Edit on a single task is enough for a specialist who should not wander.

How this works in Dayzen

In the Dayzen Project Management System, a guest is a workspace member pointed at a low-privilege role. There is no separate guest flag and no client-portal product. You then grant a share on a project, a section, or a task at view, comment, or edit.

The rest of the workspace stays closed only if that role is actually limited. A share cannot repair a role that already allows the person to view every project. Set the role first, then the share. Nothing in this flow creates an invoice or a public link that works without a membership.