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

# Manage Members

> Manage workspace members, roles, and permissions to build effective AI teams

Team management in Dify is workspace-centric. When you add members to your workspace, they get access to workspace resources based on their assigned role. Understanding these roles helps you build secure, productive AI teams.

## Team Size Limits

A workspace can include an unlimited number of members. Add as many teammates as your deployment can support.

## Workspace Roles

<AccordionGroup>
  <Accordion title="Owner">
    **Full workspace control**. Only one owner per workspace. Controls all team members, model providers, and can delete the workspace. Can transfer ownership to another member.
  </Accordion>

  <Accordion title="Admin">
    **Team and resource management**. Can invite team members, configure model providers, manage all applications, and install plugins. Cannot change member roles or remove members.
  </Accordion>

  <Accordion title="Editor">
    **Application development**. Can create, edit, and delete applications, manage knowledge bases, and use all workspace tools. Cannot manage team members or configure providers.
  </Accordion>

  <Accordion title="Member">
    **Application usage only**. Can use published applications and tools they have access to. Cannot create or modify applications.
  </Accordion>
</AccordionGroup>

## Add Team Members

Workspace owners and admins can invite new team members:

<Steps>
  <Step title="Access member management">
    Navigate to **Settings** > **Members** in your workspace.
  </Step>

  <Step title="Send invitations">
    Enter email addresses and select the appropriate role for each new member.
  </Step>

  <Step title="Handle invitations">
    New users receive registration emails. Existing Dify users are added immediately and gain access right away.
  </Step>
</Steps>

<Note>
  **Prerequisites**:

  * Set `CONSOLE_WEB_URL` to an address invitees can reach, not `localhost`. Every invitation link is built from it.
  * Configure an email service with `MAIL_TYPE`. Invitations are delivered by email, so this is required to add members.

  See [`CONSOLE_WEB_URL`](/en/3.6.x/deploy/advanced-configuration/environment-variables#console_web_url) and [Mail Configuration](/en/3.6.x/deploy/advanced-configuration/environment-variables#mail-configuration) for details.
</Note>

Invitation links expire after 72 hours by default (configurable via `INVITE_EXPIRY_HOURS`); if someone doesn't accept in time, invite again to send a fresh link.

<Info>
  Members provisioned from your identity provider are managed in the Admin Console; see [Member Management](/en/3.6.x/administer/members-management).
</Info>

## Member Management

**Removing Members**: Only workspace owners can remove team members. When removed, members immediately lose workspace access, but applications they created remain in the workspace.

**Role Changes**: Only workspace owners can modify member roles. Role changes take effect immediately and alter what the member can access across the workspace.

**Transfer ownership**: Only the workspace owner can transfer ownership. The transfer is confirmed with a verification code emailed to the owner. Once verified, the chosen member becomes the new owner and the previous owner becomes an admin.

<Note>
  Because the verification code is sent by email, ownership transfer requires a configured email service (`MAIL_TYPE`). See [Mail Configuration](/en/3.6.x/deploy/advanced-configuration/environment-variables#mail-configuration) for details.
</Note>

## Access Patterns

**Resource Inheritance**: All workspace resources (model providers, plugins, knowledge bases) are available to team members based on their role permissions.

**Application Access**: Members see applications based on sharing settings and their role. Owners and Admins see all applications. Editors see applications they can modify. Members see only published applications they're permitted to use.

**Configuration Access**: Model providers and plugins configured at the workspace level become available to all applications created by team members with appropriate permissions.

## Troubleshooting

| Symptom                                                 | What to check                                                                                                                                                     |
| :------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Invitees don't receive the invitation email             | Invitations are delivered only by email, which works only when `MAIL_TYPE` is configured. In split deployments, the worker container needs the mail settings too. |
| An invitation link won't open, or points to `localhost` | Every link is built from `CONSOLE_WEB_URL`. Set it to an address invitees can reach.                                                                              |
| An invitation link has expired                          | Links last 72 hours by default. Invite the same email again to issue a new one.                                                                                   |
| Ownership transfer never sends a code                   | The code is emailed to the Owner, so `MAIL_TYPE` must be configured.                                                                                              |