How to run multiple teams or clients in one project tool without separate accounts
Juggling clients across separate logins and duplicate accounts? Here's how multi-org support keeps each client's work, billing, and notifications walled off under one login.
All postsIf you do client work, or run more than one thing at once, you've probably lived this: you open a project tool to check on Client A, and you're staring at Client B's board. Or you've got two logins for the same product because the agency you contract for invited you to their workspace, and your own side projects live under a different email. Or you're paying for one big tenant where everyone's work piles into the same pile, and you're the one quietly keeping the walls up in your head.
I built Workunit's multi-organization support because I was tired of that exact mess. This post is about running several teams or clients in one project tool, without separate accounts, and without their work, billing, or notifications bleeding into each other.
The problem isn't multiple workspaces. It's multiple logins.
Most tools handle the first half fine. You can have a workspace per client. What they handle badly is the boundary between you and those workspaces. Accept an invite to a client's tool and you often end up with a brand-new account tied to that invite. New password to remember, two-factor set up from scratch, settings that don't follow you. Do that across four clients and you're a person with four near-identical accounts, none of which know about the others.
The fix is to separate two things that tools tend to conflate: your identity and the workspaces you work in. You are one person with one login. The organizations you belong to are many. On Workunit, accepting an invite no longer forces a separate account. If you already have one, you just log in and the new org gets added to the ones you already have. Your existing projects, settings, and two-factor setup all stay exactly where they were.
One account, many organizations
An organization on Workunit is the top-level container for a body of work: its projects, workunits, assets, and members. One account can belong to as many as you like. Three patterns cover most of the people who reach for this:
Freelancers & consultants
One org per client. Their work, their members, their billing — walled off from each other, all reachable from your single login.
Agencies & small teams
Run client engagements as separate orgs while your own internal org holds the shared playbooks and side projects.
Builders with side projects
A personal org for your own ideas, plus the orgs you've been invited to join. No second account for the moonlighting.
You don't need an invite to start. Self-service org creation lives at a dedicated page, so spinning up a workspace for a new client engagement or a weekend project is a few clicks, not a support ticket and not a duplicate account. New orgs start on the Free plan.
Switching in one click, and two tabs that don't fight
The sidebar carries an organization switcher pill right under the brand. Click it and you jump between every org you're a member of. When you belong to more than one, the chevron drops a full list, and the footer has an entry to create a new organization without leaving the menu.
There's a subtler detail that matters more than it sounds. The active organization is part of the URL — every page lives under a path scoped to a specific org. That means you can open Client A in one browser tab and Client B in another, and they stay independent. No more session-wide active org flipping under you because you switched in some other tab. The two tabs simply point at two different org URLs.
Why the URL detail is the one to notice
Tools that store the active workspace in your session, not the URL, force you into single-file work. Open a second client in a new tab and the first one quietly switches with it. Putting the org in the URL is the unglamorous decision that lets you actually have two clients open side by side.
Billing, notifications, and activity stay per-org
Walls between clients only mean something if they hold everywhere, not just on the projects list. So the separation runs through the parts people usually forget.
Billing is per-org
Each organization has its own plan, its own members, and its own Stripe subscription. One client on Free, another on Pro — they never share an invoice. Seats are derived from membership, so accepting an invite or removing a member reconciles the seat count for that org alone.
Notifications follow the org you're in
Switch orgs and the notification surface swaps to that org's data. You don't get Client A's pings while you're heads-down in Client B's workspace.
The activity feed is scoped too
The recent-activity view shows what happened in the org you're currently viewing, not a blended firehose across every workspace you belong to. Cross-org noise doesn't leak between contexts.
Per-org billing is the part that quietly fixes the money problem. You're not paying for one big tenant and splitting the cost in your head. Each engagement carries its own plan, which also means each client can be billed, upgraded, or wound down on its own schedule.
The isolation is enforced where it can't be argued with
A lot of tools draw the client boundary in the UI and hope nobody pokes at the layer underneath. That's a comfort, not a guarantee. Workunit enforces cross-organization isolation at the database layer, for every resource type — projects, workunits, tasks, assets, chat, signals, calendar, check-ins, attachments, directories.
Concretely: if you belong to both Client A and Client B, and you act inside org A, you cannot read, edit, or delete anything in org B — even though you're a legitimate member of both. A cross-org probe returns a clean "not found." Not "forbidden," which would confirm the thing exists. Not found, with no existence leak. The boundary doesn't even admit that the other org's data is there.
And your two-factor setup survives membership changes
Because identity is yours, not the org's, your two-factor setup is tied to you, not to whichever org you happened to be in when you enabled it. Leave an org, or get removed from one — including the one you set up 2FA in — and your authenticator app keeps working. No re-enrollment, no lockout.
Each client org has its own MCP endpoint
This is the part that matters if you run AI agents across clients, which I do every day. Workunit exposes an MCP server so coding agents can read and write workunits directly. With multiple orgs, each one gets its own MCP endpoint, scoped to that org by its URL.
claude mcp add --transport http client-a https://workunit.app/mcp/orgs/<org-id>The org is pinned by the URL, and the MCP tools no longer take an organization ID as an argument. That removes a whole class of accident: an agent connected to Client A's endpoint can never write into Client B's org, even if the prompt asks it to, because there's no parameter for it to get wrong. The boundary you set up for yourself extends to the agents you connect.
If an agent needs to know which orgs it can reach, the authenticated-user lookup returns every organization the caller belongs to — id, name, and role — so the client can discover the available org URLs without you leaving the conversation to copy them around.
Leaving cleanly is part of the design
Client relationships end. The tool should make that boundary as clean as the one between active orgs. A few things I made sure held:
Deleting an org doesn't log you out
When you delete an organization you stay signed in and land on your next remaining org. Other members of the deleted org are signed out, as you'd expect, but your other work is untouched.
Being removed from one org leaves the rest alone
If a client removes you, your sessions in your other workspaces continue uninterrupted. Only your access to that one org is cut.
Ownership transfer is explicit
If you own an org with other members, you can hand ownership to a member and step down in one atomic, password-protected action — useful when you're winding down your involvement, and required before you can delete an account that still owns multi-member orgs.
Account deletion is multi-org aware for the same reason. Your settings page shows one row per org with a plain-language badge — this one cascades with you, you'll leave that one, this one needs action because you still own it with other members in it. The delete button stays disabled until every blocked row is cleared, so you can't accidentally orphan a client's workspace on your way out.
One login, real walls
The whole point is to let you act like the multi-client, multi-project person you already are, without the tool punishing you for it with duplicate accounts and bleeding context. One identity that carries your settings and your two-factor setup. As many organizations as the work demands, each with its own members, billing, notifications, and agent endpoint. And a wall between them that's enforced at the database, not painted on the screen — so the separation you keep in your head is finally the separation the tool keeps for you.
Bring your AI agents and your team into one workspace
Workunit gives your agents structured context and your team a shared place to plan, track, and ship the work. Free to start, no credit card.
Dive deeper
Want to go from the idea to the actual workflow? These guides walk through it step by step.
Invite members, set roles, and manage an organization.
Wire each org's MCP endpoint into your AI clients.
2FA, ownership transfer, and account-level controls.
The full guide library covers every part of Workunit, and the community discussions are open if you want to ask.