> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Members & Roles

A **member** is a person with access to a [team](https://docs.frontic.com/admin/teams.md). Members are invited by email and assigned a **role** that controls what they can do across the team and its projects. Member access is per-team - adding someone to one team doesn't give them access to another.

## Roles

Frontic has three roles:

> [card] Owner
>
> Full control of the team - can invite or remove
> any member and transfer or delete the team. There's always at least
> one Owner.

> [card] Admin
>
> Full project access plus member management. Can invite Members
> and Admins, edit project configuration, publish releases. Can't
> remove the team.

> [card] Member
>
> Access to the projects in the team - view, edit, and use Studio
> to ship changes. Can't manage other members.

Roles apply at the team level - a Member is a Member of every project in the team. Per-project access scoping isn't a separate dial; if someone shouldn't see one of your projects, they shouldn't be in the team.

## Permissions

Members get a read-only baseline across every project surface - view storages, blocks, pages, releases, Studio jobs, Context Base documents, the team's billing, and so on. Anything that **changes state** is gated to Admin or Owner. The two tables below highlight what each higher tier unlocks over the one below.

### What Admin adds over Member

Day-to-day building, shipping, and managing the project:

| Area | What Admin can do |
| - | - |
| API Builder | Create, edit, delete Blocks, Listings, and Page routes |
| Data Storages | Create, edit, delete storages |
| Data Types | Manage composites and enums |
| Domains & Locales | Add and remove domains; add locales (delete is Owner-only) |
| Data Syncs | Configure mappings (delete is Owner-only) |
| Integrations | Connect new integrations (disconnect is Owner-only) |
| Releases | Preview a version, publish a version |
| Studio | Full access - chat, jobs, context documents, credentials, settings |
| Context Base | Author Skills/Rules/Commands/Guides; promote to team-global scope |
| API Keys | View and create Ingest/Fetch keys (delete is Owner-only) |
| Project | Edit project name and description |
| Members | Invite Members and Admins; change non-Owner roles |

### What Owner adds on top of Admin

Team-level governance and one-way destructive actions:

| Area | Owner-only |
| - | - |
| Team settings | Rename or delete the team |
| Member governance | Promote members to Owner; remove members |
| Destructive ops | Disconnect integrations, remove locales, delete API keys, delete data sync configurations |

## Inviting members

Open **Settings → Users** in the admin app and add invitations by email. Each invitation carries:

* **Email address** - where the invitation goes.
* **Role** - what the new member can do once they accept.

The recipient gets an email with a sign-in link. New members appear in the Users list once they accept.

**admin/members-invite**

Settings Users page with the invite dialog open showing email and role inputs

## Changing a role

From the Users list, open the row for the member you want to change and pick a different role. The change applies on the member's next request to the admin app - no re-login needed.

Your own row is read-only: your role shows as plain text, with no role picker and no remove option. To change your own role, ask another Admin or Owner.

**admin/members-change-role**

Users list with a row's role dropdown open showing Owner, Admin, and Member options

A few rules:

* An Owner can promote anyone, including other members to Owner. Multiple Owners are fine.
* The team always needs at least one Owner - the last Owner can't be demoted or removed without first promoting another member.
* Admins can manage Members and other Admins, but can't promote anyone to Owner or remove Owners.

## Removing a member

Removing a member revokes their access to the team and every project in it. Their work history (commits, agent sessions, configuration changes) stays attributed to them - removal is about access, not erasure.

## Related

> [card] [Teams](https://docs.frontic.com/admin/teams.md)
>
> The container members belong to.

> [card] [Billing & Plans](https://docs.frontic.com/admin/billing-and-plans.md)
>
> Plan tiers also gate which features each member can reach.

> [card] [Buddy](https://docs.frontic.com/essentials/buddy.md)
>
> Buddy operates with the role of the member currently signed in -
> a Member's Buddy can't make changes the Member can't.

> [card] [MCP Tools](https://docs.frontic.com/ide/mcp-tools.md)
>
> The OAuth token for an editor MCP carries the same role as the
> member who authorised it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.