# Permissions 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 {% embed url="" %} ![Invite team members modal with the Member / Owner role dropdown expanded](/files/8IYsTFvEHuoy0NmJGzIj) ## 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](/teams-and-billing/project-ownership.md). ## 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](/teams-and-billing/project-ownership.md) 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](/overview/reference/sharing-and-collaboration.md)) 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. ## Related * [Workspaces](/teams-and-billing/workspaces.md) * [Create and invite](/teams-and-billing/create-and-invite.md) * [Project ownership](/teams-and-billing/project-ownership.md) * [Sharing and collaboration](/overview/reference/sharing-and-collaboration.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.intangible.ai/teams-and-billing/permissions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.