How accounts, workspaces, and roles fit together

TaskJuice organizes everything you build around three nested things: an Account, the Workspaces inside it, and the Users who hold roles at each level. Get this model right once and the rest of the product, who can invite whom, who sees which client, who pays the bill, follows from it.

The short version: your account is your agency, each workspace is one client engagement, and a person is either staff (works across the whole account) or a client (read-only inside a single workspace). Those two populations never mix.

The three levels

Account

An account is your agency. It owns your subscription plan, your branding, your billing contact, and every workspace you create. There is exactly one account per agency, and you get it the moment you finish the setup wizard. The person who runs that wizard becomes the account Owner.

The account is also where your staff live. Everyone on your team holds an account role rather than being added to workspaces one at a time.

Workspace

A workspace is one client engagement. You create one workspace per client, and each workspace holds that client's workflows, connections, run history, and the client users who can see them. A workspace belongs to exactly one account and cannot be shared across accounts.

Workspace URL slugs are unique per account, not globally. Two different agencies can each have a workspace named dashboard without colliding, because the slug is scoped to your account.

How many workspaces you can create depends on your plan:

The limit is checked when you create a workspace. If you are on Growth with 5 workspaces and try to add a sixth, the create step is rejected. Renaming or editing an existing workspace never counts against the limit. To raise the ceiling, move up a plan. See Manage workspaces for the create and rename flows.

User

A user is a person with a TaskJuice login. Where a user fits in the hierarchy is decided by which kind of role they hold, and that is the part most people get wrong at first. There are two separate role layers, and they behave very differently.

Two role layers, one composition rule

TaskJuice has account roles and workspace roles. They are not the same list, and they do not stack the way you might expect.

Account roles govern the whole account. They are Owner, Admin, and Member. Anyone holding one of these is agency staff.

Workspace roles govern a single workspace. There are only two: Admin and Client.

Here is the rule that ties them together, and it is the most important thing on this page. Anyone who holds any account role automatically gets Admin-level access on every workspace in the account. There is no per-workspace invite step for your team. Add a teammate once at the account level and they can build, invite, and manage settings in every client workspace you have, present and future.

That derived access is the workspace Admin role. It is never written down anywhere as a per-workspace assignment. It is computed from the account role each time access is checked. The only workspace role that is ever explicitly stored on a workspace is Client.

So the two ways to be an Admin on a workspace come from opposite directions:

• A teammate is a workspace Admin because they hold an account role. You cannot remove them from one workspace while keeping them on others, because there is nothing per-workspace to remove.
• A client is a workspace Client because you invited them to that specific workspace. They have no account role at all.

The isolation invariant: staff or client, never both

On a given account, a person is either staff or a client. They cannot be both at the same time.

Concretely, a user who holds any account role on your account cannot also be added as a client member of one of your workspaces, and a client member cannot be granted an account role without first being removed as a client. TaskJuice rejects either attempt rather than letting the two states coexist.

This is what keeps client access genuinely scoped. A client you invite to one workspace sees only that workspace, through the client portal, and never the agency dashboard or your other clients. Staff see everything in the account. There is no in-between state where someone is "mostly a client but also pokes around the agency side."

What each role can do

Account roles

All three account roles can read everything in the account and build workflows. They diverge on the management capabilities.

A Member can do the day-to-day building: create and edit workflows, set up connections, and view everything in the account. A Member cannot invite anyone, touch workspaces, change branding, or go near billing.

An Admin is a Member plus the team and workspace management powers: inviting teammates and clients, creating and renaming workspaces, and editing branding. An Admin still cannot access billing, transfer ownership, or delete the account.

The Owner has everything an Admin has, plus the three account-level powers: billing, transferring ownership, and deleting the account. There is exactly one Owner per account, and ownership moves only through an explicit transfer, never through an invite. See Transfer ownership for how the single Owner role moves.

Workspace roles

A Client is your external end-customer. They get read-only-plus access to their one workspace: they can watch runs, kick off a manual run, and reauthorize the apps they connected, but they cannot edit a workflow, invite anyone, or change settings.

A workspace Admin is any of your staff, by way of the composition rule above. Everything a Member or higher can do at the account level, they can do inside each workspace.

A worked example

Say you run an agency called Acme. Here is how a few people land in the model.

1. You finish the setup wizard

   You create the Acme account and the wizard makes you the Owner. It also creates your first workspace. You can now build, invite, manage branding, and handle billing.

2. You invite a colleague as an Admin

   You invite dana@acme.com from the team page and pick the Admin role. Once Dana accepts, she holds the account Admin role. She immediately has full Admin access on every Acme workspace, including ones you create next week. You never touch any individual workspace to grant this.

3. You add a junior builder as a Member

   You invite sam@acme.com as a Member. Sam can build workflows and connections in any workspace and read everything, but cannot invite people, create workspaces, or see billing.

4. You invite a client to one workspace

   Inside the workspace for your client Globex, you invite ops@globex.com. There is no role picker here: the role is fixed to Client. Globex can view their runs, trigger one manually, and reauthorize their own connected apps, but only inside the Globex workspace. They never see your other clients or the Acme dashboard.

Dana, Sam, and you are staff with account roles. The Globex contact is a client. Nobody is both.

When the model says no

The isolation invariant is the rule you are most likely to bump into. Two attempts fail by design:

• Inviting a teammate to an email that is already a client on your account. Account staff and workspace clients are mutually exclusive on the same account, so the invite is rejected rather than putting that person in both states. Remove them as a client first if you genuinely want them to become staff.
• Inviting an Owner. Owner is never an invitable role. The invite dialog only offers Admin and Member. The single Owner role moves only through Transfer ownership, and the new owner must already be an Admin on the account before you can hand it over.

A separate guard protects the Owner slot itself: you cannot delete a user who still owns an account. They have to transfer ownership first, which keeps every account with exactly one Owner at all times.

Next steps

• Roles and permissions: the full capability matrix for every account and workspace role.
• Invite teammates: invite staff as Admin or Member, and resend or revoke pending invitations.
• Manage workspaces: create and rename workspaces and work within your per-plan limit.