> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/users-and-access-management/user-roles-and-permissions.md).

# User roles and permissions

The seven roles an ilert user can hold, what each one may do, and how to change a user's role.

Every ilert user holds exactly one account-wide role. The role decides what they can see and change everywhere in the account. [Teams](/users-and-access-management/teams.md) can grant additional permissions on top of it within a single team's context.

## The roles at a glance

| Role                                | In one line                                                                | Plan            |
| ----------------------------------- | -------------------------------------------------------------------------- | --------------- |
| [**Stakeholder**](#stakeholder)     | Sees only the incidents, services and status pages shared with their teams | Scale or higher |
| [**Viewer**](#viewer)               | Account-wide read-only access, no alert or on-call involvement             | Pro or higher   |
| [**Guest**](#guest)                 | Sees nothing until added to a team                                         | Any             |
| [**Responder**](#responder)         | Works alerts and takes on-call shifts, changes no configuration            | Any             |
| [**User**](#user)                   | Read and write on everything except users, connectors and account settings | Any             |
| [**Admin**](#admin)                 | A User who also manages users, teams and connectors                        | Any             |
| [**Account owner**](#account-owner) | An Admin who also controls account, subscription and billing settings      | Any             |

### Stakeholder

Stakeholders see the incidents they have been added to as a subscriber, plus the status pages and services their teams grant them. They see nothing else — no alerts, no alert sources, no escalation policies. To give a stakeholder access to a resource, add them to a team that owns it.

Stakeholders cannot hold a separate [team role](/users-and-access-management/teams.md#team-roles): their access is team-scoped already.

Requires the [Scale plan](https://www.ilert.com/pricing) or higher, sold in packages.

### Viewer

Viewers have account-wide read-only access. They see every alert, incident, service, and configuration — schedules, escalation policies, alert sources — and every report, across the whole account. Think of a Viewer as a Responder without the ability to act.

The role suits engineering managers, executives, and support leads who need visibility without being paged.

| Viewers can                                                                               | Viewers cannot                                    |
| ----------------------------------------------------------------------------------------- | ------------------------------------------------- |
| See every page a Responder can, with action buttons disabled                              | Accept or resolve alerts                          |
| Use the dashboard, read-only                                                              | Join on-call schedules or escalation policies     |
| Read every report                                                                         | Receive alert notifications                       |
| Comment in alert chat                                                                     | Be a target of a call routing **Route call** node |
| Manage saved filters                                                                      | Hold a team role                                  |
| Subscribe to incidents, services and status pages, and manage those notification settings |                                                   |

Where a Stakeholder is team-scoped and built for MSP scenarios, a Viewer is account-wide.

An existing user can only be downgraded to Viewer once they are out of every escalation policy and schedule and have no alert notification settings configured.

Requires the [Pro plan](https://www.ilert.com/pricing) or higher.

### Guest

Guests can sign in, but see no resources and no other users until they are added to a team. What they can do inside that team depends on their team role.

### Responder

Responders manage alerts in the web app and the mobile app: accepting, resolving, commenting. They create and modify nothing — no alert sources, no schedules, no escalation policies — with one exception: a Responder can add themselves as an override to a schedule.

### User

Users create and modify alert sources, schedules, escalation policies, and other resources. They cannot create, modify or invite users of any role, cannot manage teams, and cannot touch account settings. A User can edit a resource that belongs to a team they are not in, but cannot change which team owns it.

### Admin

An Admin is a User who can also create and modify users and teams, change other users' roles, create and edit connectors, and add or remove team ownership of resources. Admins cannot reach account settings.

### Account owner

The account owner is an Admin who can also reach account settings, the subscription, and billing. There is exactly one per account, and only the current account owner can transfer the role to another user — under **Settings** → **Account settings**.

The account owner is also the only role that no one else in the account can recover: nobody can clear their [two-factor authentication](/users-and-access-management/two-factor-authentication-mfa.md#clearing-2fa-for-someone-else).

### Team Admin, which is not a role

A **User** cannot create or modify teams. An Admin can, however, grant a User the right to administer one particular team. That makes them a Team Admin — a permission granted per team, not an account-wide role. See [team roles](/users-and-access-management/teams.md#team-roles).

## Role permissions

| **Operation**                                          | **Stakeholder** | **Viewer** | **Guest** | **Responder** | **User** | **Admin** | **Account owner** |
| ------------------------------------------------------ | :-------------: | :--------: | :-------: | :-----------: | :------: | :-------: | :---------------: |
| Modify profile settings                                |        ✅        |      ✅     |     ✅     |       ✅       |     ✅    |     ✅     |         ✅         |
| Subscribe to incidents, services and status pages      |        ✅        |      ✅     |     ❌     |       ✅       |     ✅    |     ✅     |         ✅         |
| Manage alerts                                          |        ❌        |      ❌     |     ❌     |       ✅       |     ✅    |     ✅     |         ✅         |
| View objects, e.g. schedules and escalation policies\* |        ❌        |      ✅     |     ❌     |       ✅       |     ✅    |     ✅     |         ✅         |
| View reports\*\*                                       |        ❌        |      ✅     |     ✅     |       ✅       |     ✅    |     ✅     |         ✅         |
| Add themselves as override to a schedule               |        ❌        |      ❌     |     ❌     |       ✅       |     ✅    |     ✅     |         ✅         |
| Add anyone as overrides to schedules                   |        ❌        |      ❌     |     ❌     |       ❌       |     ✅    |     ✅     |         ✅         |
| Modify objects, e.g. schedules and escalation policies |        ❌        |      ❌     |     ❌     |       ❌       |     ✅    |     ✅     |         ✅         |
| Manage teams                                           |        ❌        |      ❌     |     ❌     |       ❌       |     ❌    |     ✅     |         ✅         |
| Manage users                                           |        ❌        |      ❌     |     ❌     |       ❌       |     ❌    |     ✅     |         ✅         |
| Add or remove team ownerships to/from resources        |        ❌        |      ❌     |     ❌     |       ❌       |     ❌    |     ✅     |         ✅         |
| <p>Manage account</p><p>settings and subscription</p>  |        ❌        |      ❌     |     ❌     |       ❌       |     ❌    |     ❌     |         ✅         |

\*Stakeholders see the incidents, services and status pages shared with them through team membership or a subscription. Viewers have account-wide read-only access to all objects.\
\*\*Reports show only what the reader is allowed to see. Someone with no access to a schedule sees none of its on-call data. See [report visibility](/users-and-access-management/teams.md#data-visibility-in-reports).

## Change a user's role

{% hint style="warning" %}
Requires Admin or account owner privileges.
{% endhint %}

{% stepper %}
{% step %}

### Open the user

In the sidebar, go to **Settings** → **Users** and click the user's name.
{% endstep %}

{% step %}

### Edit the profile

Click **Edit**.
{% endstep %}

{% step %}

### Pick the new role

Choose it from the **Role** dropdown. ilert describes each role beneath the dropdown as you select it.
{% endstep %}

{% step %}

### Save

Click **Save**. The new role applies immediately, on the user's next page load.
{% endstep %}
{% endstepper %}

Downgrades are refused while the user still holds something the new role cannot: a Responder cannot become a Viewer while they sit in an escalation policy or a schedule. Remove them from those first.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ilert.com/users-and-access-management/user-roles-and-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.