> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chevre.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Members and Permissions: Role-Based Access in Chevre
> Chevre uses role-based access control to manage what each team member can see and do. Learn about roles, invitations, and project-level permissions.
Chevre uses role-based access control (RBAC) to manage what each team member can see and do in your workspace. Every member is assigned one of four roles, and each role comes with a fixed set of capabilities. By combining workspace-level roles with project-level visibility settings, you can give your team exactly the access they need — no more, no less.
## Workspace Roles
The table below summarizes what each role can do across the workspace.
| Role | Description | Can manage members | Can manage billing |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------------ |
| **Owner** | Full access to every resource in the workspace, including the ability to delete the workspace and manage billing. Automatically assigned to the person who created the workspace. | ✅ Yes | ✅ Yes |
| **Admin** | Full access to all projects and workspace settings. Can invite and remove members and change member roles, but cannot access billing or delete the workspace. | ✅ Yes | ❌ No |
| **Editor** | Can create, edit, and delete workflows and projects they have access to. Cannot change workspace settings or manage other members. | ❌ No | ❌ No |
| **Viewer** | Read-only access to projects they have been explicitly added to. Cannot create or modify any resources. | ❌ No | ❌ No |
The workspace **Owner** always retains full access to every resource in the workspace, regardless of any project-level visibility settings. If you need to restrict a project from most of your team, use **Private** visibility — but know that the Owner will always be able to see it.
## Inviting Members
Invite new members to your workspace from **Settings → Members → Invite**.
Navigate to **Settings → Members** in the left sidebar of your workspace dashboard.
Click the **Invite Members** button in the top-right corner of the Members page.
Type one or more email addresses separated by commas. Each address will receive a separate invitation email.
Choose the role you want to assign to the invitees: **Admin**, **Editor**, or **Viewer**. You can change a member's role at any time after they accept the invitation.
Click **Send Invitations**. Each invitee receives an email with a link to accept the invitation and join the workspace. Pending invitations appear in the **Pending** tab of the Members page until accepted or revoked.
You can also invite members programmatically using the Chevre API. The following example sends an invitation to a new Editor:
```bash theme={null}
curl --request POST \
--url https://api.chevre.io/v1/users/invite \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"email": "colleague@example.com",
"role": "editor"
}'
```
A successful response returns the pending invitation object:
```json theme={null}
{
"id": "inv_01hx9k2pqr4j5mz8n3vb6wctde",
"email": "colleague@example.com",
"role": "editor",
"status": "pending",
"created_at": "2024-06-01T10:30:00Z",
"expires_at": "2024-06-08T10:30:00Z"
}
```
Invitations expire after **7 days**. If an invitee misses the window, resend the invitation from **Settings → Members → Pending**.
## Changing a Member's Role
Navigate to **Settings → Members** in the workspace sidebar.
Locate the member in the list. Use the search field to filter by name or email if the workspace has many members.
Click the member's current role label to open the role dropdown.
Choose the role you want to assign. The change takes effect immediately — the member does not need to log out and back in.
Only **Owners** and **Admins** can change member roles. An Admin cannot promote another member to **Owner** — only an existing Owner can do that.
## Removing a Member
Navigate to **Settings → Members** in the workspace sidebar.
Locate the member you want to remove.
Click the **⋯** menu next to the member's name and select **Remove from workspace**. Confirm the action in the dialog that appears.
Removing a member immediately revokes their access to the workspace and all its projects. Any workflows or automations they created remain intact and continue to function — removing a member does not affect workspace data.
You cannot remove the **last Owner** of a workspace. Before removing the current Owner (including yourself), you must first promote at least one other member to the Owner role. If a workspace loses its only Owner due to account closure or other circumstances, contact [support@chevre.io](mailto:support@chevre.io) to resolve the situation.
## Project-Level Permissions
Workspace roles define what a member can do across the entire workspace, but project visibility adds a second layer of access control at the project level.
| Workspace Role | Shared Project | Private Project (not added) | Private Project (added) |
| -------------- | ----------------------------- | ----------------------------- | ----------------------------- |
| **Owner** | Full access | Full access | Full access |
| **Admin** | Full access | Full access | Full access |
| **Editor** | Can create and edit workflows | No access — project is hidden | Can create and edit workflows |
| **Viewer** | Read-only access | No access — project is hidden | Read-only access |
Owners and Admins always have access to every project, regardless of visibility. Editors and Viewers only see **Private** projects they have been explicitly added to.
To add an Editor or Viewer to a specific private project, open the project, go to **Settings → Access**, and click **Add Members**. Select the workspace members you want to grant access to. Their workspace role determines what they can do once inside the project — you cannot grant a Viewer editing rights at the project level.
Use **Private** projects for sensitive or in-progress work that only a subset of your team should see, and **Shared** projects for stable, company-wide processes. This combination lets you take full advantage of RBAC without having to create separate workspaces for every team boundary.