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

# Members and roles

> Invite teammates to your workspace, choose their role, and manage access with owner and member permissions.

Everyone in your workspace shares one brain. You manage the people who can reach it from **Settings → Members**.

## Roles

There are two roles: **owner** and **member**. Both have full read and write access to the brain. The owner role is unrelated to a document's `Owner` field, which assigns a document to a person and grants no permissions.

| Capability                                                     | Owner | Member |
| -------------------------------------------------------------- | ----- | ------ |
| Create, edit, and delete documents, folders, and tags          | Yes   | Yes    |
| Invite people, change roles, deactivate and reactivate members | Yes   | No     |
| Manage access tokens for external agents                       | Yes   | No     |
| Manage billing and workspace settings                          | Yes   | No     |

A member can do everything with brain content that an owner can. Members can open billing settings to see the current plan and usage, but cannot change the plan or open the billing portal.

<Note>
  There are no per-document or per-folder permissions, and there is no read-only role. Anyone you add to the workspace can edit anything in the brain.
</Note>

## Invite a teammate

<Steps>
  <Step title="Open the invite form">
    Go to **Settings → Members**. Owners see an **Invite a teammate** form above the roster.
  </Step>

  <Step title="Enter the email and pick a role">
    Type the person's email address and choose **Member** or **Owner**. The role defaults to Member.
  </Step>

  <Step title="Send the invite">
    Select **Send invite**. Tatara emails the person a link to join your workspace. The invitation appears in **Pending invitations** until it is accepted or revoked.
  </Step>
</Steps>

The invitation email names you and your workspace and has an **Accept invitation** button. The link expires 7 days after it is sent.

An invite is rejected if the email already belongs to an active member of your workspace, already has a pending invitation, or already belongs to another workspace. It is also rejected if you have no author seats left (see [How seats are counted](#how-seats-are-counted)).

## Accept an invitation

Opening the invite link shows a page confirming who invited the recipient and which workspace they are joining.

* **Signed out:** they can create an account or sign in to an existing one. The account must use the email the invitation was sent to.
* **Signed in with the invited email:** they select **Accept** and join immediately with the role you chose.

Some links cannot be accepted. Each case explains itself on the page:

| What they see             | What happened                                                                                          |
| ------------------------- | ------------------------------------------------------------------------------------------------------ |
| Wrong account             | They are signed in with a different email than the one invited. They can sign out and switch accounts. |
| Invitation expired        | More than 7 days passed. Ask an owner to resend it.                                                    |
| Invitation revoked        | An owner cancelled the invitation.                                                                     |
| Already accepted          | The link has been used. They can sign in instead.                                                      |
| Invitation not found      | The link is not valid. Ask an owner to send a new one.                                                 |
| One workspace per account | Their account already belongs to another workspace.                                                    |

## Manage pending invitations

Owners see every unaccepted invitation under **Pending invitations**, with the email, role, who sent it, and when it expires. Each row has two actions:

* **Resend** issues a fresh link and a fresh 7-day expiry. The previous link stops working.
* **Revoke** cancels the invitation. The link stops working and the seat it was holding is released.

## Remove someone's access

There is no delete. An owner deactivates a member instead, using the button on their row in the roster. The person stays listed with a **Deactivated** status so you keep a record of who was in the workspace.

A deactivated person keeps their sign-in but loses all access to the workspace. On their next visit they see a page telling them their access was deactivated and to contact a workspace owner. Selecting **Reactivate** on their row restores their access with the same role.

<Warning>
  A workspace must always keep at least one active owner. If you are the only active owner, you cannot change your own role or deactivate yourself. Promote another member to owner first.
</Warning>

## One workspace per account

An account can belong to only one workspace. If someone tries to accept an invitation while they already belong to another workspace, the invitation cannot be accepted. Reactivating a former member also fails if they have since joined a different workspace.

## How seats are counted

Your plan sets the number of author seats. A seat is consumed by:

* every **active** member, including owners
* every **pending** invitation, until it is accepted or revoked

Deactivated members do not consume a seat. If you run out of seats, revoke a pending invitation, deactivate someone who no longer needs access, or move to a plan with more seats. See [Plans and limits](/account/plans).
