Building Client Portals Without Code: Guest Roles in Zinx OS

Every agency owner has had the same conversation with the same prospect at some point. The prospect says, "Do you have a client portal? I want to see project status without having to email you." The agency owner says yes, and then quietly stresses about which third-party portal product to bolt on, how to keep it in sync with the project tool, and how much it will cost per client.

The honest answer is that you do not need a client portal product. You need a permission system flexible enough to let clients into the same workspace your team uses, scoped to exactly what they should see.

Here is how that works in practice.

What a client portal actually needs to do

Strip away the marketing and a client portal is doing three things:

1. Show the client the current status of their project, in plain language
2. Let the client comment on work or ask questions
3. Let the client see and download relevant files

Billing usually rides alongside it, but it does not have to live in the portal. In Zinx OS, invoices are emailed straight to the client as a branded message, so the portal itself stays focused on status, conversation, and files. Everything else is optional.

Every project management tool already has tasks, comments, and files. The reason you cannot use the same tool for your client portal is that the permissions model is too coarse. Either the client can see your entire workspace, including your internal notes, the other clients, and the team chat, or they can see nothing.

What you need is a role that has read access to one project and nothing else. We unpacked the full role model in workspace permissions that scale.

The guest role done right

A guest role done correctly has three properties:

Scoped to one or more projects. Not to the workspace. A guest can be invited to project A and stay completely invisible to projects B through Z, even though all those projects live in the same workspace.

Read by default, write where it matters. Guests should not be able to move tasks around your kanban board. They should be able to comment on tasks, react to messages, and request changes through structured channels.

Nothing granted, nothing seen. A guest never gets your timesheets, invoices, CRM, or other projects, because those permissions are not part of the guest role to begin with. You opt them into one project's board, chat, and files by name, and anything you do not grant stays invisible.

When the permission system supports all three, the "client portal" is just a project that you have shared with one extra guest.

A simple setup walkthrough

Say you are starting work for a new client. Here is how the portal comes together in practice.

You create a new project for the engagement. Inside the project, you set up your kanban board with the columns you normally use: Backlog, In Progress, Review, Done. You add the initial tasks.

You then add one column specifically for client interaction. Call it "For client review." This is where you will put items that need a client decision: design concepts, copy drafts, scope clarifications.

You invite the client as a guest and assign them as the project's client, which is what makes this one project visible to them. You then grant them the project's kanban board and chat by name. Time entries, invoices, and the CRM are never part of the guest role, so there is nothing to hide; they are simply never granted.

You send them the invitation link. They sign in with their Google account. They land in the workspace, see only this one project, and immediately understand the layout because it is just a kanban board with a chat panel.

Done. That is the client portal.

What the client sees and does

In their view, the client can:

• See the current status of every task in the project
• Comment on tasks in the "For client review" column
• Send messages in the project chat channel
• View and download files attached to the project

In their view, the client cannot:

• See any other project, including projects for other clients
• See your time entries, invoices, or the CRM
• See any internal chat channel you have not granted them
• See the team's other workspaces, their billing data, or their personal settings

The guest user is not "outside the system looking in through a portal product." They are inside the workspace, but they only see the slice that matters to them.

Why the same-workspace model wins

Most agencies that try external portal products end up dropping them after six months. The reasons are predictable:

The data is always slightly out of date. Sync errors are inevitable. The kanban shows a different status than the portal. The client sees stale information and loses trust.

The interaction layer is poor. The portal lets the client comment, but the comment lands in a separate inbox. Someone on your team has to copy the comment back into the project. Latency creeps in.

The cost adds up. Portal products often charge per client. If you have twenty clients, you pay for twenty portal seats on top of your project tool.

When the portal is just a permission scope on your existing workspace, all three problems go away. The data is the same data. The interaction lands directly on the task or in the channel. A guest still takes a seat in your workspace, the same as any member, but you are not paying for a separate portal product on top of your stack, and there is nothing to keep in sync.

The best client portal is the absence of a client portal. It is your project tool, with the right walls in the right places.

Where guest roles get tricky

A few configurations to be deliberate about.

Billing stays in email. Guests do not get invoice access inside the portal, and invoice visibility is workspace-wide rather than per-project, so you would not grant it to a client anyway. Send invoices by email instead; each one arrives as a clean, branded message without exposing the rest of your billing history.

File downloads. Guests should be able to download files attached to the project, including PDFs and design assets. Be careful about confidential internal documents leaking into the wrong shared folder.

Chat moderation. Some agencies prefer a guests-cannot-start-channels rule. The guest can chat in the project channel, but cannot spin up new channels and tag random team members. This keeps your team's attention focused.

Off-boarding. When the engagement ends, revoke the guest. The guest's comments and chat history remain in the project. Their access ends instantly. There is no portal account to forget about.

When the guest model breaks down

The guest model handles 90 percent of agency client relationships cleanly. Where it gets harder is when the client themselves is a multi-person team, with stakeholders who have different permissions on their side (the CMO sees billing, the brand manager only sees creative).

In those cases, you may want to invite multiple guests with slightly different role configurations. A guest who only sees the design board. A guest who sees the design board and the budget but not the chat. This is more work to set up, but the system supports it.

For the typical solo-stakeholder client engagement, one guest invite is enough. Five minutes of setup replaces the entire client portal procurement conversation.

Try it on your next engagement

The next time you start a new client engagement, instead of asking "do we need a portal?", ask "what scope should the guest see?" Set it up the way described above, and let the client into the workspace.

You will save the portal subscription. You will eliminate the sync errors. You will give the client a faster, more honest view of the work. Start a free workspace and you can configure your first client guest in under five minutes.