Roles and permissions

The exact capability matrix for every account and workspace role in TaskJuice, with the slugs used in code.

TaskJuice has two role layers that compose. Account roles govern your agency staff across the whole account. Workspace roles govern a single client workspace. This page lists every role, its exact slug, and what it can and cannot do.

If you want the conceptual model first, read Account, workspace, and user hierarchy.

Account roles

Account roles apply to your staff across every workspace in the account. There are exactly three, and there is no viewer or billing-manager role.

Role	Slug	Rank
Owner	`account-owner`	3
Admin	`account-admin`	2
Member	`account-member`	1

The rank is used for ordering only. A higher rank does not silently grant a lower role's restricted capabilities. Each capability is checked explicitly per the matrix below.

Account capability matrix

Capability	Owner	Admin	Member
`read` (view everything)	yes	yes	yes
`write` (build workflows, connections)	yes	yes	yes
`inviteTeammate`	yes	yes	no
`manageWorkspaces` (create, rename, delete)	yes	yes	no
`manageBranding`	yes	yes	no
`billing` (subscription, payment, plan)	yes	no	no
`transferOwnership`	yes	no	no
`deleteAccount`	yes	no	no

What each role can do, in plain terms:

Member can build and view everything: create and edit workflows, connections, and resources across all workspaces. A Member cannot invite teammates, manage workspaces, change branding, touch billing, transfer ownership, or delete the account.
Admin does everything a Member does, plus invites teammates and clients, manages workspaces, and manages branding. An Admin cannot access billing, cannot transfer ownership, and cannot delete the account.
Owner has full control: everything an Admin does, plus billing, transfer ownership, and delete the account.

One owner per account

Every account has exactly one Owner. You cannot invite someone as Owner. Ownership moves only through transfer ownership, which atomically demotes the current Owner to Admin and promotes the target. The target must already be an Admin on the account.

Admin-tier checks admit the Owner

The Owner outranks the Admin. Any surface gated to "admin required" is also reachable by the Owner. So when this page says a capability requires account-admin, the Owner has it too.

Workspace roles

A workspace is one client engagement. Workspace roles govern that single workspace. There are exactly two, and there is no member or viewer workspace role.

Role	Slug	Rank
Admin	`workspace-admin`	2
Client	`workspace-client`	1

Workspace capability matrix

Capability	Admin (`workspace-admin`)	Client (`workspace-client`)
`read`	yes	yes
`triggerRun` (manually run a workflow)	yes	yes
`rotateOwnCredential` (rotate own connection)	yes	yes
`build` (create and edit workflows)	yes	no
`invite`	yes	no
`manage` (workspace settings)	yes	no
`forms.orphan_notification`	yes	no

Client is the agency's external end customer. A Client has read-only access to the workspace: they can view execution history, trigger manual runs, and rotate their own connected-app credentials. A Client cannot edit workflows, invite anyone, or change settings.
Admin has full powers inside the workspace. This role is never assigned by hand (see below).

How the two layers compose

The workspace-admin role is derived, not stored. Anyone who holds any account role gets full Admin access to every workspace in the account automatically. There is no per-workspace invite step for your staff.

A user's effective role on a workspace resolves in this order:

Check for an account role on the owning account
If the user holds any account role (account-owner, account-admin, or account-member) on the account that owns the workspace, their effective workspace role is workspace-admin.
Fall back to the stored workspace role
Otherwise, use the explicit role stored in the workspace member list. The only role ever stored there is workspace-client.
Otherwise no access
If neither applies, the user has no access to the workspace.

This is why the only role you can assign on a workspace is Client. You never set a teammate as workspace Admin: holding an account role grants it.

Staff and clients are mutually exclusive

On a single account, a user is either staff (holds an account role) or a Client on a workspace, never both. If you try to add an existing staff member as a workspace Client, the platform rejects it, and the reverse is rejected too. This keeps client access isolated from staff access.

What each role can reach

Surface	Owner	Admin	Member	Workspace Client
View all workspaces in account	yes	yes	yes	no
View only their own workspace	n/a	n/a	n/a	yes
Build and edit workflows	yes	yes	yes	no
Trigger a manual run	yes	yes	yes	yes
Rotate own connected-app credential	yes	yes	yes	yes
Invite teammates	yes	yes	no	no
Invite clients to a workspace	yes	yes	no	no
Create, rename, delete workspaces	yes	yes	no	no
Edit account settings and branding	yes	yes	no	no
Manage billing and subscription	yes	no	no	no
Transfer ownership	yes	no	no	no
Delete the account	yes	no	no	no

An account-role holder sees every workspace in the account. A Client sees only the one workspace they belong to.

Where roles are assigned

Role	How it is granted
`account-owner`	Assigned to the founder when the account is created. Afterward, only via transfer ownership.
`account-admin`	Invite a teammate as Admin from the Team page. See Invite teammates.
`account-member`	Invite a teammate as Member from the Team page (the default selection).
`workspace-client`	Invite a client to a workspace. The role is fixed to Client with no role picker.
`workspace-admin`	Never assigned directly. Derived for any account-role holder via the composition rule above.

Failure cases

These are the errors you hit when a role lacks the capability for an action.

Action	Required capability	Failure
Edit account settings or rename slug	`account-admin` (or Owner)	HTTP 403 "Tenant admin required" for a Member.
Invite a teammate as Owner	n/a (not allowed)	`AccountOwnerInviteDisallowedError`. Owner is never invitable.
Transfer ownership when not the Owner	`account-owner`	HTTP 403 "Only the account owner can transfer ownership".
Transfer ownership to a non-Admin	target must be `account-admin`	HTTP 400 "Target must be an account-admin on this tenant".
Transfer ownership to yourself	n/a	HTTP 400 "You are already the account owner".
Add staff as a workspace Client	n/a (isolation invariant)	Rejected: a user cannot be both staff and a Client on the same account.

A Member cannot edit account settings

A Member has read and write, but not manageWorkspaces, manageBranding, or billing. Calls that change account settings return HTTP 403 "Tenant admin required". To let someone change settings or branding, promote them to Admin from the Team page.

Webhook