# Team & Roles

The Fluxis Dashboard lets organization Owners and Admins manage collaborators—team members who can access the dashboard, configure integrations, and manage API credentials.

## Dashboard access

Manage your team at:

**`/app/team`**

Only collaborators with **Owner** or **Admin** roles can access this section.

## Collaborator roles

| Role | Dashboard access |
| ---- | ---------------- |
| **Owner** | Full access; can modify other Owners' roles |
| **Admin** | Manage team members, API keys, accounts, and most settings |
| **Operator** | Operational tasks (scope defined by dashboard permissions) |
| **Guest** | Limited read-oriented access |

Roles are assigned as an array—a collaborator may hold multiple roles, though typical assignments use a single primary role.

## Team management actions

| Action | Who can perform | Description |
| ------ | --------------- | ----------- |
| List members | Owner, Admin | Paginated list (`page`, `page_size`) |
| Invite / create | Owner, Admin | Add collaborator with name, email, and roles |
| Update profile | Owner, Admin | Change name, phone, country |
| Update roles | Owner, Admin | Change a collaborator's role assignment (`PUT /team/roles/:id`) |
| Remove member | Owner, Admin | Delete a collaborator (Owners cannot be deleted) |

::::warning
**Owners cannot be deleted.** Attempts to remove a collaborator with the Owner role are rejected.
::::

::::note
Profile updates (`PUT /team/:id`) apply only to collaborators who currently hold **Admin** or **Owner** roles. Operators and Guests cannot be updated through this endpoint.
::::

## Creating a team member

Provide:

| Field | Required | Description |
| ----- | -------- | ----------- |
| `first_name` | Yes | Given name |
| `last_name` | Yes | Family name |
| `email` | Yes | Login email (must be unique) |
| `roles` | Yes | Array of role strings (`owner`, `admin`, `operator`, `guest`) |
| `phone` | No | Contact phone |
| `country` | No | Country code |

New collaborators receive credentials through the dashboard onboarding flow (set password on first login).

## Role hierarchy

```mermaid
flowchart TD
    O[Owner] --> A[Admin]
    A --> Op[Operator]
    Op --> G[Guest]
```

- **Owner** — highest privilege; cannot be deleted via the team API
- **Admin** — day-to-day management including API keys at `/app/api-keys`
- **Operator / Guest** — reduced scope for specific operational needs

::::note
Dashboard role names (`owner`, `admin`, …) are separate from **API credential roles** (`read`, `write`) on API keys. A collaborator's dashboard role controls UI access; API key roles control REST API permissions.
::::

## API key management by role

| Dashboard role | `/app/api-keys` access |
| -------------- | ---------------------- |
| Owner | Full CRUD |
| Admin | Full CRUD |
| Operator | No access |
| Guest | No access |

Creating API keys requires 2FA verification—see [Two-Factor Authentication](/docs/developers/two-factor-auth).

## Best practices

1. **Minimize Owners** — keep the Owner count small; use Admin for most team members
2. **Use role-appropriate access** — Operators and Guests should not manage credentials
3. **Remove departed members promptly** — delete collaborators when they leave your organization
4. **Separate API keys by service** — create distinct keys per integration rather than sharing one key across teams

## Organization vs account scope

Collaborators belong to an **organization**. Organization-level API keys can access all accounts under that organization (subject to API role permissions). Account-specific resources (webhooks, settlement addresses per account) are managed in account context within the dashboard.

## Related documentation

- [API Credentials](/docs/developers/api-credentials) — REST API keys (Owner/Admin only)
- [Two-Factor Authentication](/docs/developers/two-factor-auth) — required for sensitive actions
- [Sign Up](/docs/merchant-integration/sign-up) — how organizations are provisioned