> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Team and roles > Invite your team to the portal, choose roles for each person, and see exactly which permissions each role holds. Every person who uses the portal is a member of your organization with one or more roles. A member with several roles holds every permission of each of them. The roles decide which pages they see and what they can change. Roles govern the portal only; your application's access to the API is set by its API key (see [Authentication and access](/authentication)). ## How it works 1. An administrator invites a person by email from **Settings, then Team** and picks one role. After the person joins, an administrator can add or remove roles from the same page; every member keeps at least one. 2. The person accepts the invitation and signs in. 3. At sign-in, the portal reads the person's roles and their combined permissions from their session. Pages and actions check permissions from that set. 4. An action none of the person's roles allows is refused with 403, usually "Forbidden: insufficient permissions". A page they cannot open sends them elsewhere, usually to Overview, and most such pages are hidden from the sidebar. ## Roles | Role | Meant for | In short | | --------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Admin | The person who runs your organization's account | Members, roles, keys, environments, webhooks and runs. Can delete engines. Does not edit engine configuration | | Developer | The engineer who builds the integration | Everything technical: keys, environments, webhooks, full engine configuration, runs and traces | | Member | The day-to-day operator or subject expert | Reads engines and results, chats with conversation instances, edits the safe part of engine configuration, reviews | | Reviewer | A domain expert who checks results | Review and annotations only, on runs assigned to them | Some pages are operated by Nexio and are not opened by any of these roles. ## Permissions by role Permission names are exact. A check mark means the role holds the permission, directly or because a stronger permission implies it. | Permission | What it allows | Admin | Developer | Member | Reviewer | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ----- | --------- | ------ | -------- | | `members:manage` | Open Team, invite, revoke invitations, remove members | ✓ | | | | | `roles:manage` | Change a member's roles | ✓ | | | | | `api_keys:manage` | Create, rename and revoke API keys; change environments | ✓ | ✓ | | | | `environments:manage` | Open the Environments page | ✓ | ✓ | | | | `webhooks:manage` | Manage webhook endpoints and deliveries | ✓ | ✓ | | | | `engines:read` | See engines, their contracts and conversation instances | ✓ | ✓ | ✓ | | | `engines:configure-safe` | Edit the safe subset of engine configuration | | ✓ | ✓ | | | `engines:manage` | Create engines and conversation instances; edit all configuration | | ✓ | | | | `engines:delete` | Delete an engine | ✓ | | | | | `runs:read` | See every run and the Metrics page | ✓ | ✓ | ✓ | | | `runs:write` | Submit runs from the Playground and the Run page (choosing the test key also needs `api_keys:manage`); chat with an instance | ✓ | ✓ | ✓ | | | `runs:trace` | See the Trace tab of a run | | ✓ | | | | `pii:reveal:test` | See unmasked personal data in test runs | ✓ | ✓ | ✓ | | | `review:use` | Open Review and work assigned items | | | ✓ | ✓ | | `annotations:write` | Annotate runs | | | ✓ | ✓ | Implied permissions: * `engines:manage` implies `engines:configure-safe` and `engines:read`. * `engines:configure-safe` implies `engines:read`. * `runs:write` implies `runs:read`. * `review:use` and `annotations:write` imply each other. The safe subset of configuration exists for Comparison and Evaluate engines: their scoring or analysis dimensions, weights, overlays, label maps and, for Comparison, the data source. Every other setting, including prompts, schemas, redaction settings and enrichment sources, and every change to other engine types, needs `engines:manage`. See [The portal](/platform/portal#engines). ## Reviewers and moderators A reviewer works the items assigned to them. Without `runs:read`, a reviewer can open only the runs assigned to them, and the Runs page is hidden. A Member also holds `review:use`, so a Member can review as well as run engines. A moderator puts runs into review, assigns items to reviewers, uses bulk actions, sees every queue, and deletes items. Nexio moderates your review queue for you. See [Review](/connections/review). ## Invite and manage members Open **Settings, then Team** (needs `members:manage`). The page lists members, pending invitations, and recent membership activity. | Action | How | Needs | | -------------------- | ---------------------------------------------------------------------- | ---------------- | | Invite | Enter an email address and choose Admin, Developer, Member or Reviewer | `members:manage` | | Revoke an invitation | Revoke it from the pending list | `members:manage` | | Change roles | Pick one or more roles for the member; at least one must stay | `roles:manage` | | Remove a member | Remove them from the organization | `members:manage` | The portal refuses these changes: * changing your own roles; * demoting the only Admin of the organization; * removing yourself; * removing the only Admin. ## Pages Nexio operates Some pages are operated by Nexio for you, such as connections, extraction review, run review moderation and the learning loop. See [What Nexio operates for you](/platform/portal#what-nexio-operates-for-you). ## Sign-in The portal uses hosted sign-in from WorkOS. A person accepts their invitation and signs in through that hosted page. A person who signs in without belonging to an organization sees a page that says so. Your email address is managed by your sign-in and cannot be changed in the portal; you can edit your first and last name under **Settings, then Account**. ## Acting on behalf of a person from your application Portal roles do not apply to API calls. When your application calls the API on behalf of a signed-in person, it names that person in a request header, and the platform narrows what the call can see to that person's authority. The header narrows what the API key already grants. See [Authority and scope](/data-services/scope). What each area of the portal does. API keys, scoped keys and capabilities.