Permissions

Member versus Owner permissions on a team workspace. Who can edit projects, who can manage seats, who can change billing.

A team has two roles: Member and Owner. Members can do the work; Owners can do the work plus manage the team. Pick the right role per teammate at invite time, change it later if the role changes.

Watch

Invite team members modal with the Member / Owner role dropdown expanded

What does what

Action
Member
Owner

Open and edit projects

Render against the team's credit balance

Save assets to Team Assets

Save custom styles at team level

Share projects via email

Invite new team members

Remove team members

Change another member's role

Add or remove seats

Change the team's plan

Manage payment methods

Buy credit packs

Delete the team

Transfer team ownership

The split is intentional: Members work, Owners administer. Most agencies have one or two Owners (the agency principal, the office manager) and the rest of the team as Members.

Owner-only actions are enforced server-side, not only in the UI. A Member who hits a billing or team-settings API route directly is rejected with a 401; the role check runs at the API layer.

Project transfer is gated by the project creator, not by team role

One action that lives outside the Member / Owner table: transferring an individual project between workspaces is restricted to the project creator, regardless of team role. A team Owner who didn't create a specific project can't transfer it; the creator (the user whose ID is on projects.created_by) is the only role that can. The enforcement runs in the server action, not the UI alone. See Project ownership.

Choosing the right role

For each teammate:

  • Owner if they need to manage seats, billing, or other team members.

  • Member if they only need to work in the team's projects.

The default at invite time is Member. Promote to Owner deliberately, not by default; an over-permissioned team is a quiet way to lose track of who can do what.

For agencies, the typical pattern:

  • Agency principal: Owner.

  • Office manager / ops lead: Owner (for seat management and billing).

  • Creative leads, producers: Member.

  • Individual contributors: Member.

  • Contractors: Member with deliberate scope; remove when the engagement ends.

Changing a role

Roles are set at invite time. There isn't an in-product flow today to change a member's role after they've joined the team. To move someone between Member and Owner, an existing Owner removes the member and reinvites them with the new role.

This is a known UX gap; expect it to be addressed when the team-admin surface gets its next pass.

Multiple owners

A team can have multiple Owners. The setting is unrestricted in count; pick what makes sense for the team's actual administrative needs. Common arrangements:

  • One Owner for solo-led teams.

  • Two Owners for partner-led teams or agencies with a clear principal-and-ops split.

  • More than two Owners when the team's administrative load is genuinely distributed.

All Owners have equal authority. There's no "primary Owner" with super-admin status; every Owner can manage seats, billing, and transfers identically.

Removing a member

Owner-only action.

  1. Find the member's row.

  2. Click the remove icon.

  3. Confirm.

The member loses access to the team workspace immediately. Their authored projects remain in the team workspace; you can transfer ownership of specific projects via Project ownership if needed.

A removed member's seat becomes available for a new invite. No partial-cycle refund.

Limits and known issues

  • No granular permissions today. A Member can edit any project in the team workspace, not just specific ones. Per-project access controls aren't exposed in the current UI.

  • No "view only" role. Anyone in the workspace is at minimum a Member with edit access. For external reviewers who shouldn't edit, share the project via the email-share flow (Sharing and collaboration) without adding them as a member.

  • The last Owner cannot demote themselves to Member. Self-demotion of the last Owner is blocked at the UI, server action, and RLS policy layers; the only path is to invite another Owner first, or delete the team entirely. Every team needs at least one Owner at all times.

  • No in-product role change today. Roles are set at invite. To change a member's role, an Owner removes and reinvites them at the new role. See Changing a role above.

Last updated

Was this helpful?