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

# Personas and permissions

> How access works in Frayme, and the role templates the guides assume for analysts, engineers and managers.

export const Shot = ({id, alt, caption}) => <Frame caption={caption}>
    <img className="block dark:hidden rounded-lg" src={`/images/guides/${id}.light.png`} alt={alt} loading="lazy" decoding="async" />
    <img className="hidden dark:block rounded-lg" src={`/images/guides/${id}.dark.png`} alt={alt} loading="lazy" decoding="async" />
  </Frame>;

Frayme has no built-in "analyst" or "engineer" role. Access is a set of **scopes** attached to a **role** that your tenant defines. The three personas in these guides are recommended scope bundles that a tenant admin creates once in **Team → Roles & Permissions**.

## How access works

* A member belongs to one tenant with one role.
* A role holds scopes from a fixed catalog. Each scope has a `read` and a `write` tier, and `write` always includes `read`.
* The reserved **admin** role bypasses every scope check inside its tenant. It is created with the tenant and cannot be edited.
* Frayme operators are **super-admins**. They can act across tenants and see the Admin group in the sidebar.
* Role names are lowercase letters and hyphens, for example `senior-analyst`.

## The scope catalog

| Group          | Scopes                                        | Grants                                                                                                      |
| -------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Cases          | `cases:read`, `cases:write`                   | See cases; claim, decide, tag, note and send information requests                                           |
| Case override  | `case_override:read`, `case_override:write`   | Override a final decision on a decided case (the read tier exists only to pair with write)                  |
| Workflows      | `workflows:read`, `workflows:write`           | Open the builder; save, activate and delete flows                                                           |
| Queues         | `queues:read`, `queues:write`                 | See review queues; manage them in Settings                                                                  |
| Risk           | `risk:read`, `risk:write`                     | Open Risk Management; edit rules, thresholds, velocity metrics, **and** Settings → Decline Reasons and Tags |
| Webhooks       | `webhooks:read`, `webhooks:write`             | See and manage webhook endpoints and delivery history                                                       |
| Team           | `team:read`, `team:write`                     | Open Team; invite and remove members                                                                        |
| Roles          | `roles:read`, `roles:write`                   | See and create roles                                                                                        |
| API keys       | `apikeys:read`, `apikeys:write`               | See and create API keys                                                                                     |
| Analytics      | `analytics:read`, `analytics:write`           | Open Analytics (write is reserved)                                                                          |
| Data sources   | `datasources:read`, `datasources:write`       | See providers; connect, disable and remove them, and manage the AI provider key                             |
| Attributes     | `attributes:read`, `attributes:write`         | Read and define custom attributes through the API                                                           |
| Communications | `communications:read`, `communications:write` | See templates; manage templates and the communication webhook                                               |

<Note>
  Two gates surprise people. Editing **Decline Reasons** and **Tags** in Settings needs `risk:write`, not `cases:write`. Managing the AI provider key needs `datasources:write`.
</Note>

## Recommended role templates

| Role             | Scopes                                                                                                                                                                        | Who it is for                                                                                                              |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `analyst`        | `cases:write`, `queues:read`, `communications:read`, `team:read`                                                                                                              | Works the queue and the console, can request information and see who is on the team                                        |
| `senior-analyst` | everything in `analyst` plus `case_override:write`, `risk:write`                                                                                                              | Also overrides final decisions and maintains decline reasons and tags                                                      |
| `engineer`       | `workflows:write`, `datasources:write`, `apikeys:write`, `webhooks:write`, `risk:write`, `attributes:write`, `queues:read`, `communications:read`, `team:read`, `cases:write` | Builds flows, connects providers, owns the integration surface; `cases:write` lets them submit test cases from the builder |
| `manager`        | the reserved **admin** role                                                                                                                                                   | Sets up the tenant, manages people, oversees and corrects decisions                                                        |

`queues:read` and `communications:read` are on the engineer template because the Review node's queue picker and the Send RFI node's template picker read those lists. `cases:write` is there because **Submit case** in the builder creates a case, which means an engineer can also decide cases; drop it if that is not acceptable and have a manager run the test submissions. `team:read` lets analysts and engineers open **Team** read-only.

## What each template sees

| Surface                                            | analyst | senior-analyst | engineer | manager |
| -------------------------------------------------- | ------- | -------------- | -------- | ------- |
| Dashboard, Decision Queue, Decision Console, Cases | ✓       | ✓              | ✓        | ✓       |
| Workflow                                           | —       | —              | ✓        | ✓       |
| Risk Management                                    | —       | —              | ✓        | ✓       |
| Data Sources                                       | —       | —              | ✓        | ✓       |
| Team                                               | view    | view           | view     | manage  |
| Settings → General                                 | ✓       | ✓              | ✓        | ✓       |
| Settings → Queues                                  | view    | view           | view     | manage  |
| Settings → Decline Reasons, Tags                   | view    | manage         | manage   | manage  |
| Settings → Communication                           | view    | view           | view     | manage  |
| Settings → AI                                      | view    | view           | manage   | manage  |
| Settings → API                                     | view    | view           | manage   | manage  |
| Approve, Decline, Request Information              | ✓       | ✓              | ✓        | ✓       |
| Override a final decision                          | —       | ✓              | —        | ✓       |

Every Settings tab is rendered for every member. "view" means the tab opens but its controls are read-only or are rejected with a permission error when used; the Queues and API tabs still show their **Create** buttons to everyone.

Opening a page your role cannot see shows an access-denied panel rather than an empty page.

<Shot id="shared/access-denied-01" alt="Access Denied panel" caption="A role with cases:read only opening the Workflow page." />

## Frayme super-admins

Super-admins are Frayme staff. They see the **Admin** group (Tenants, Super Admins, Poller, Tenant Switch) and **Regulatory Docs**, can switch the tenant they act in, and bypass every scope check. Tenant admins cannot grant super-admin.

## Create these roles

A tenant admin creates the templates in **Team → Roles & Permissions → Create Role**, ticking the scopes listed above. [Team and roles](/guides/admin/team-and-roles) shows each step.