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

# Team & roles

> Invite members, assign roles, and manage who can do what in your organization.

Your organization's members and their roles live under **Settings › Members**.
This page is for owners and admins who manage the team: inviting people,
choosing what each can do, and removing or restoring access. Access control is
role-based and enforced everywhere in MerchantOps — every action is checked
against the acting member's role, and every member only ever sees their own
organization's data.

## Roles

Each member holds one or more **roles**, and a role is a bundle of permissions.
MerchantOps ships four core roles, from most to least privileged:

| Role       | Broadly can                                                                                                                                                                         |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything, plus organization-level control: manage members and their roles, billing, and API keys.                                                                                 |
| **Admin**  | Manage the catalog, pricing, publishing, enrichment, lakehouse, and content settings; invite and view members. Cannot change roles, remove members, or manage billing and API keys. |
| **Editor** | Create and edit catalog and pricing data, run enrichment, and prepare batches. Cannot approve, delete, or change organization settings.                                             |
| **Viewer** | Read-only access across the catalog, pricing, and jobs.                                                                                                                             |

<Note>
  Roles are additive and enforced per action — a member with a role that lacks a
  permission simply can't take that action, and the affected controls are hidden
  or disabled. Approving, deleting, and publishing are gated separately from
  editing, so you can let someone prepare changes without letting them approve
  their own work.
</Note>

Some organizations have additional roles beyond the four core ones (for example
a pricing- or catalog-focused role). The role picker shows every role
configured for your organization, so assign whichever fits the person's job.

<Warning>
  A few actions are **Owner-only**: changing another member's roles, removing a
  member, managing billing, and creating or revoking API keys. An Admin can invite
  new members and view the team but cannot change roles or remove anyone.
</Warning>

## Invite a member

<Steps>
  <Step title="Open Settings › Members">
    You need permission to invite members (Owner or Admin).
  </Step>

  <Step title="Enter their details">
    Provide the person's email address, and optionally their name. Choose the
    role(s) to assign — you can change these later.
  </Step>

  <Step title="Send the invitation">
    MerchantOps emails the person an invitation link. They appear in the members
    list as **pending** until they accept and sign in, at which point they
    become **active**.
  </Step>
</Steps>

<Tip>
  If someone doesn't receive their invitation, invite them again — re-inviting a
  pending member resends the email. MerchantOps surfaces the real reason when an
  invitation can't be sent, rather than silently failing.
</Tip>

## Change a member's roles

An Owner can update any member's roles at any time from the members list. The
change takes effect on the member's next authenticated action; there may be a
short delay while their session refreshes.

## Remove and reactivate members

Removing a member **deactivates** them: they immediately lose access, but the
record is retained so you can restore it later.

<Steps>
  <Step title="Remove">
    An Owner removes a member from the members list. The member is deactivated
    and can no longer sign in. You cannot remove yourself.
  </Step>

  <Step title="Reactivate">
    A deactivated member can be reactivated from the same list, restoring their
    previous roles.
  </Step>
</Steps>

<Note>
  If a member was invited but never accepted (their email was never verified),
  reactivating them isn't possible — MerchantOps re-invites them instead, using
  the same single action, so a fresh invitation email goes out.
</Note>

## How access is enforced

MerchantOps is multi-tenant. Authentication and role checks run on every
request, and all data is scoped to your organization — there is no way for a
member of one organization to read or change another's catalog, pricing, or
settings. Roles govern *what* a member can do; organization scoping governs
*whose* data they can do it to.

## Related settings

<CardGroup cols={2}>
  <Card title="Lakehouse sharing" icon="share-nodes" href="/settings/lakehouse-sharing">
    Control what your organization contributes to shared knowledge.
  </Card>

  <Card title="Content settings" icon="pen-nib" href="/settings/content-settings">
    Set the tone and structure of AI-generated content.
  </Card>
</CardGroup>