> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/manage-the-platform/manage-users-and-roles.md).

# Manage users and roles

Create users and service accounts, and grant the roles that give them access.

## Your goal

Give each person and each integration exactly the access it needs - no more - and know how that access spreads down your organisation hierarchy.

## Expected outcome

Every human user and every technical integration has an account of the right type, and at least one role on the right organisation.

{% hint style="warning" %}
A user **needs at least one role** on an organisation to have any access to mediarithmics products - Navigator, Computing Console, or the API. Creating a user is not enough.
{% endhint %}

## Where this lives

Users and roles are managed in **Settings > Organisation > Users & Roles**. You land on the users list, which shows the users created in every organisation you have access to for the current community. Switch to the roles view with the selector on that page.

Users can be created at **organisation** or **community** level, and a user can see all users in their organisation as well as in its children.

## The two account types

| Type                | Can access                                                                         | Use it for                      |
| ------------------- | ---------------------------------------------------------------------------------- | ------------------------------- |
| **User**            | The mediarithmics user interfaces - Navigator and Computing Console - and the APIs | People.                         |
| **Service account** | The APIs only. No interface access.                                                | Integrations, scripts, servers. |

{% hint style="info" %}
Prefer a service account to bear a long-term API token: it avoids cancelling a token because a person left. See [Manage API access](/setup-and-monitor/manage-the-platform/manage-api-access.md).
{% endhint %}

## The roles

| Role                           | Access                                                                                        | Notes                                                                                                                                                                                                                                                        |
| ------------------------------ | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Community administrator**    | Read and write on all settings and objects of an entire community                             | Can only be assigned at community level. Can create, edit, and delete roles for all the community's organisations, and has extra permissions over an organisation administrator - modifying password policies and managing identity providers, for instance. |
| **Organisation administrator** | Read and write on the settings and objects of an organisation and all its child organisations |                                                                                                                                                                                                                                                              |
| **Editor**                     | Read and write on the objects of an organisation and all its child organisations              | No settings access.                                                                                                                                                                                                                                          |
| **Reader**                     | Read on an organisation and all its child organisations                                       |                                                                                                                                                                                                                                                              |

Roles are **automatically inherited** by child organisations. Setting a role on an organisation gives the user access to that organisation, and the role is inherited by everything below it. In the roles view you can show inherited roles by activating **Display inherited role**.

```mermaid
flowchart TD
    C["Community<br/>role granted here"]
    O1["Organisation A<br/>inherits"]
    O2["Organisation B<br/>inherits"]
    S["Sub-organisation<br/>inherits"]
    C --> O1
    C --> O2
    O1 --> S
```

## Create a user

{% tabs %}
{% tab title="A person" %}

1. Click **Add User**.
2. Select the user type **User**.
3. Enter **First name**, **Last name**, and **Email**.
4. Select the **Organisation** the user is created in.
5. Click **Save**.

You are then redirected to the add-role screen - the user has no access until you complete it.

Notes:

* All fields are mandatory.
* The organisations list contains the organisations you have access to for the community you are connected to.
* The new user receives an email with a link to set a password and access the platform.

{% hint style="warning" %}
If the new user receives no email, check that the address on the profile is correct. If it is, contact your account manager.
{% endhint %}
{% endtab %}

{% tab title="A service account" %}

1. Click **Add User**.
2. Select the type **Service account**.
3. Enter a **Name** and a **Description**.
4. Select the **Organisation** it is created in.
5. Click **Save**.

You are then redirected to the add-role screen.

Notes:

* All fields are mandatory.
* An email address is generated automatically from the name. It cannot be used to log in to the interfaces.
* Once created, you can generate an API token for the service account - see [Manage API access](/setup-and-monitor/manage-the-platform/manage-api-access.md).
  {% endtab %}
  {% endtabs %}

## Grant a role

{% stepper %}
{% step %}

### Add the role

Click **Add Role**, then select the **User** - you can look one up by first or last name - the **Organisation**, and the **Role** to assign on that organisation. Save.

All fields are mandatory. The organisations list is filled with the organisations you have access to for the community you are connected to; the users list contains the users of all organisations you have access to.
{% endstep %}

{% step %}

### Check the level you granted it on

Because roles are inherited downwards, granting a role high in the hierarchy grants it everywhere below. Grant on the narrowest organisation that does the job.
{% endstep %}
{% endstepper %}

## Change or remove access

| Task              | How                                                                                                                                                                                        |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Edit a role**   | Find the user in the list, open the drop-down, and choose **Edit User**. Only the role is editable.                                                                                        |
| **Delete a role** | Find the role, open the drop-down, and choose **Delete Role**. All inherited roles are deleted as well.                                                                                    |
| **Edit a user**   | Find the user, choose **Edit User**, update, and save. You cannot change the **Type** or the **Organisation** of any user, and you cannot change the generated email of a service account. |
| **Find a user**   | Enter a name, first name, last name, or email address in the **Filter on User** field.                                                                                                     |
| **Delete a user** | Find the user, open the drop-down, and choose **Delete User**, then confirm.                                                                                                               |

## Your own account

Each user manages their own first and last name, and their API tokens, under **Settings > My Account**.

## Verify

* Every new user has at least one role, or they cannot log in to anything.
* No role is granted at a higher level than needed, given inheritance.
* Integrations use service accounts rather than personal accounts.

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Set up single sign-on</strong></td><td>Authenticate users through your own identity provider.</td><td><a href="/setup-and-monitor/manage-the-platform/set-up-single-sign-on.md">Set up single sign-on</a></td></tr><tr><td><strong>Manage API access</strong></td><td>Tokens and signature keys for machine access.</td><td><a href="/setup-and-monitor/manage-the-platform/manage-api-access.md">Manage API access</a></td></tr><tr><td><strong>How mediarithmics works</strong></td><td>Communities, organisations, and the hierarchy roles are inherited through.</td><td><a href="/setup-and-monitor/understand-mediarithmics/how-mediarithmics-works.md">How mediarithmics works</a></td></tr></tbody></table>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mediarithmics.io/setup-and-monitor/manage-the-platform/manage-users-and-roles.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.