---
title: "Users, roles and permissions reference"
description: "Every field of the user form, the rules of the user grid, the matrix columns and grant sets, and the corner cases of the role editor — the companion to the Manage users, roles and permissions guide."
type: "reference"
audience: [admin]
keywords: [user edit form, user grid, permission matrix, granting type, permission type, Manage Role, admin UI permissions, admin-only permissions, deleted role, API key, AI assistant limit, password policy, notes for the user]
ui_path: "Admin → Users & access → User management"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Users, roles and permissions reference

The companion to [Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md). The guide has the
steps, the caveats and the fix-it table; this page holds every field, the grid rules, the
matrix columns and grant sets, and the corner cases.

## How a role decides access

Three facts explain almost every "why can't this user see X" question.

**1. The role's base role decides which half of the product you get.** Every role is built on
one of two static base roles — **Admin** or **Network** — and that choice is what routes a user
to the Admin area or the Account area. The console bounces you to your own section if you ask
for the other one, and decides which is yours from the *role's* base role.

> **Note:** the only thing that moves a user between the Admin and Account areas is assigning
> them a role whose base role differs.

The base role also fixes *which permission groups exist* for that role. An **Admin**-based role
gets two: **User Management** and **Ad Server management**, plus the **Admin UI permissions**
checkbox list. A **Network**-based role gets every other group — targeting, capping, banner
types, analytics, invocation codes and the rest — and no Admin UI checkboxes.

**2. A permission has to be granted, not just exist.** The permission editor lists every
permission the product knows, so a permission always **appears** in the editor — but if no grant
has ever been stored for a role it has no value, the cell reads as a dash, and the feature it
gates is invisible to everyone in that role. See the corner cases below for what to do about it.

**3. Each cell is an operation crossed with a grant.** The columns of a group are its
**permission types** (the operations); the value in a cell is a **granting type** (how far the
grant reaches). Both lists are fixed in code — see [Operations](#operations-the-matrix-columns)
and [Grants](#grants-the-cell-values) for the complete sets and which combinations the editor
actually offers.

For how permissions then combine with entity shares, see
[Sharing and permission model](https://epom.com/ad-server/docs/concepts/sharing-permission-model.md).

### Who can change a role or give a user more access?

- **Changing a role's matrix** needs the *User roles & permissions* (or *Admin roles &
  permissions*) admin page **and** *Manage Role* on that role. You can only grant an Admin UI
  page your own role already has, and only Epom support can hand out *Manage Role*. Taking
  rights away is always allowed.
- **Moving a user to another role** needs *Create* on the target role; you also cannot edit a
  user who sits in a role you cannot create.
- **Giving access to one advertiser or site** does not need a role change at all — share it
  ([Shares](https://epom.com/ad-server/docs/guides/collaboration/shares.md)); the role decides *what kind* of things a user can do,
  shares decide *on which* entities.
- A permission changed on a role applies to **every user in that role**. To change one person,
  create a role for them (**Add role** → *Copy from* their current role) and move them into it.
- If nobody in your company has the Admin area, ask Epom support or your account manager to
  change the role.

## User edit form

| Field | Section | Notes |
|---|---|---|
| Username | Login information | Required, unique, up to 64 characters. |
| Password | Login information | Required when creating. On an existing user the field is replaced by a **Change password** button; leaving it untouched keeps the current password. |
| First name, Last name | Personal information | Optional. |
| E-mail | Personal information | Required, up to 64 characters. |
| Phone, Country, State/Province, Company, Website URL | Personal information | Optional. |
| Active | Additional information | On by default. An inactive user cannot sign in and cannot be switched into. |
| Role | Additional information | Required. See [Assign a role](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md#assign-a-role). |
| Referer, Referral ID | Additional information | Referral-program linkage. |
| Internal notes | Additional information | Free-form operator notes; contact-us messages are appended automatically. Not shown in the user's console (labelled *Comments* before release 155). |
| Notes for the user | Panel below the form (existing users only) | Notes the user reads on their Notes tab, newest first: optional title (up to 200 characters) and text (up to 5,000). Each note is saved by its own **Add** / **Save**, not by the form, and says when the user read it (**Read on …**) or **Not read yet**; a change to its title or text makes it unread again. |
| API key | Additional information | Read-only field with a **Generate** button; the key is never typed by hand and Save never writes it. **Generate** mints a new key on the server and replaces the live one immediately, without waiting for Save, and only for a user whose role you may hand out — and not at all for a user whose role was deleted, until it is given one again. It needs a saved user, so **Add** shows the field without the button. On this Admin page both field and button are ungated — the *API Key Access* permission gates them only on the account-side user list. |
| AI assistant monthly limit per user, $ | Additional info | This user's monthly cap for the [AI assistant](https://epom.com/ad-server/docs/guides/collaboration/ai-assistant.md), in USD. Empty = the network default (set by Epom support), else $20. 0 = no allowance. Only administrators and users holding the *Ad-server fees* admin permission may change it (*Billing Tab* does not grant it); anyone else sees it read-only and can still save the rest of the form. Applies on the network's and the platform's key, never on the user's own key. |
| Limit the user set on their own key, $ | Additional info | Read-only: the cap the user set for themself in **Preferences → AI assistant**. It applies only while they run on their own Anthropic key. Empty = no limit. |
| Receive newsletters / Receive notifications by email | Additional information | Both on by default. |
| Created | Additional information | Required. Editable audit date. |

### Password rules

Password rules are enforced by the server: at least 8 and at most 64 characters, not starting
or ending with a space, and not one of the passwords on the common-password blocklist. The form
itself checks only the 8–64 length (and the e-mail format) before it sends.

> **Note:** the policy also refuses a password that contains the account's own username or
> email local part — on these forms as everywhere else.

Changing an existing user's password here works like the user changing it themselves: the
user's other sessions are signed out, any password-reset links they hold stop working, and they
receive the *password changed* notification.

The password typed on **Add** is never mailed to the new user. Activation mail carries a
single-use **set-password link** instead, minted when the event fires and only for an active
account. It expires after the configured initial-set lifetime (72 hours by default) and issuing
a new one invalidates the old.

### Companion panels

On an existing user the form is followed by panels that save independently of it: **User
interface preferences** (navigation style, show entity IDs, advanced analytics view, display
language), **Payment details** (needs the *User Payment Details* permission, and renders
read-only on a view-only grant), **User scheduled events**, **Notes for the user**, and a
**Default share** panel when the network has one to offer. If your role has the referral-program
permission the page also grows a second tab, **Referral program**, holding the referral share,
referred clients and referral revenue, and the grid gains a **Show referrals** checkbox.

### Notes for the user

- Up to 5,000 characters of plain text with its line breaks kept, plus an optional title of up
  to 200 characters. **Add** saves the note at once; each note has **Edit** and **Delete**, and
  Delete asks first.
- The user reads them on their **Notes** tab, between Analytics and Preferences, newest first,
  each with the date it was written but not who wrote it. The tab needs *Notes Tab Visible*,
  off on every role until ticked, and at least one note: with the permission and no notes the
  user sees no Notes tab until the first note is added. The panel warns when the user's role
  lacks the permission, and while the user has no notes it says the tab appears with the first
  one. Without that
  permission the notes are not in the user's profile over the REST API or the AI assistant either
  (the assistant's `whoami` reports the permission as `may.notesTab`).
- A new note is unread: the Notes tab carries the number of unread notes on a badge (on a
  phone, on the bottom bar), and an unread note has a dot before its first line. The user clears
  it with the check mark by a note's date (**Mark as read**; shown when the pointer is over the
  note, always on a phone) or with **Mark all as read** over the list, which counts them —
  opening the tab does not.
- Each note in the panel says **Read on** and when, or **Not read yet**. Changing a note's title
  or text makes it unread again; a save that changes neither keeps it read.
- Only the user can mark notes as read: when you switch into the user, their Notes tab shows what
  is unread but has no check marks and no **Mark all as read**, and the server refuses the call.
- You see who added and who last changed each note, and when. Adding, changing and deleting
  notes takes the same right as editing the user; a role that may only view the user sees the
  notes without the buttons.
- The **Internal notes** field in the form stays yours: the user does not see it in the console,
  and the messages they send through the contact form are added to it.

## The user grid

Columns: Username, E-mail, First name, Last name, Role, Status, Referer, Referred users, Date
created. Every column except *Referred users* sorts, server-side. Filters: **Search** (username
or email), **Role**, **Show active**, and **Show referrals** when your role has the referral
program permission.

| Control | Enabled when |
|---|---|
| Add | always |
| Edit | the selected user's role is one you hold **Update** on |
| Switch | the selected user is **Active** and their role is one you hold **Access** on |
| Delete | the selected user's role is one you hold **Delete** on, and the row is not you |

The grid itself is filtered the same way: it lists only users whose role you hold **View = All**
on — plus, if you hold **Manage Role** on any role, the users whose role was deleted (see below).
A user you may not view is **absent**, not greyed out — so a grid that looks far shorter than the
network's real headcount usually means the *User Management* group of your role grants View on
only a few roles.

The **Switch** restriction is enforced on the server, not only by the disabled button: a switch
into a user whose role you lack Access on is refused with **403 Access denied**. The **Role**
select on the form likewise offers **every** role on the network, including ones you are not
allowed to hand out; the check happens on save — the target role must be one you hold **Create**
on, *and* so must the role the user is in today — otherwise the save answers **403 Access
denied**. That second half is what stops a lower-privileged administrator taking over a more
privileged account by re-saving it into a role they can assign.

**Users whose role was deleted.** Deleting a role does not delete its users: they stay, with no
role, and signing in grants them nothing. They are listed, with an empty *Role* column, only to a
role that holds **Manage Role** on at least one role — administering accounts, not merely
creating them — and to it **Edit** and **Delete** are enabled, because what such an account
needs is a role: give it one in the edit form. Two limits apply:

- A user that was an **administrator** before its role was deleted is listed, edited and deleted
  only by an administrator.
- Its API key cannot be regenerated until it has a role again.

A **Shared** View grant on a role does less than **All**: you can name that role's users as
share recipients, but you can open the record of only the users you own — the statistics
accounts you created yourself. Opening any other user of that role is refused, and the grid
lists none of that role's users either way.

## Operations (the matrix columns)

| Column | What it governs | Grants offered |
|---|---|---|
| Create | may create entities of this type / hand out this role | **Enabled / Disabled** |
| View | may see them | the row's own set, normally None / All / Shared |
| Update | may change them | the row's own set |
| Delete | may remove them | the row's own set |
| Access | may switch into a user of this role | the row's own set |
| Share | may re-share the entity | the row's own set |
| Manage Role | may edit this role's matrix | **Enabled / Disabled**. Granted by Epom support; the editor does not offer you this column |
| *(no heading)* | the single column of a group of on/off features: one feature permission per row | the row's own set |

Only **Create** and **Manage Role** override the grants offered by the row; every other column
falls back to the granting-type set declared on the permission itself. A group of on/off feature
permissions has a single column with no heading.

## Grants (the cell values)

Cells show the grant by name, in your interface language. Which set a cell offers depends on the
permission (English names below):

| Set | Values | Used by |
|---|---|---|
| Entity scope | None, All, Shared | Entity-type permissions — inventory, campaigns, templates, actions. The default set for a permission that declares none. |
| Entity scope with links | None, All, Shared, Linked, Shared and linked | Entity permissions that also understand linked-only visibility. |
| Feature toggle | Enabled, Disabled | Most feature permissions, plus the Create and Manage Role columns. |
| Feature toggle with read-only | Enabled, Disabled, Read-only | Feature permissions whose card can render disabled instead of hidden. |
| Navigation style | Trees and grids, Trees, Grids | The account navigation preference. |
| Analytics view | Simple, Extended, Unique | Advanced-report depth. |

There is no "Own" grant — a user's own entities are covered by **All** or by a share, never by a
separate grant value.

## Adding a role

**+ Add role** opens an inline row: a **Role name**, the **Static role** it is built on, and an
optional **Copy all settings from** an existing role. Copying takes that role's Admin UI
permissions and its whole matrix; without it the new role starts with just *User roles &
permissions*. The **Static role** list offers **Network** and — only if you hold the *Create
ADMIN-based role* permission — **Admin**; the older static roles are retired and cannot be used
for a new role. **Rename role** and **Delete** act on the tab that is currently open, and both
answer **403 Access denied** for a role you do not hold *Manage Role* on. Deleting drops you onto
the first remaining role.

## Corner cases and gotchas

> **Corner case:** a permission whose default grant was never stored is invisible rather than
> missing. Its row renders in the editor — the editor lists every permission the product knows —
> but the cell is a dash and every user in that role is refused. It mostly shows up on an
> installation that was upgraded rather than set up fresh. **The fix is to set the cell yourself
> and save** — the save stores the missing grant. If a feature is missing for every role, look for
> a dash in its row before assuming the feature is not installed.

> **Corner case:** twenty-seven permissions are **admin-only** and are stripped from the *User
> roles & permissions* screen — DMP targeting and pre-targeting, sites and banners approval and
> the two moderation modes, bid-floor management, video RTB configuration, banner view tracking,
> the accounting-period confirmations, the advertiser completeness delay, the advertiser analytics
> column, the advanced report type and its default view, the four raw-log and cookie report types,
> header bidding, the three AJAX invocation-code permissions, and inactive-template property
> updates. Two whole groups go with them — **DMP** and **Billing Management**. To grant any of
> these to an account-level role you must open that role on the **Admin roles & permissions** page
> instead, which shows more groups and rows for the same role than the user page does. The server
> enforces this too: without **Admin roles & permissions** the admin page answers *Access denied*
> instead of showing the matrix, and a save that changes an admin-only row is refused the same
> way.

> **Corner case:** you cannot delete your own account. The Delete button stays disabled on your
> own row, and the server refuses the request as well.

> **Corner case:** you can open any role's tab and read its matrix, but a role editor **saves**
> only roles you hold *Manage Role* on, and the save is refused outright — the whole save, not one
> row — if it would grant rights over a role you do not manage. The editor therefore offers you
> only what it will accept. In the *User Management* group it lists just the roles you manage, one
> row each, without the **Manage Role** column. Two grants stay restricted on the server as well:
> **Manage Role** itself can only be handed out by Epom support, and you cannot tick an **Admin
> UI** checkbox your own role doesn't already have. Removing grants is always allowed. A save the
> editor would not have offered you, for example one posted by hand, answers **403 Access denied**.
>
> A role you hold no *Manage Role* on is therefore *missing* from the *User Management* table,
> not greyed out, whichever role's tab is open; the other groups of that tab show in full.

> **Corner case:** removing an Admin UI checkbox does more than hide a sidebar entry. The same
> permission is re-checked on the request itself, so the page and the actions it starts both stop
> working, not just the link. The check also honours a per-user permission override, so a user can
> hold an admin page their role does not grant.

> **Corner case:** the Admin UI checkbox list is delta-checked on save. You may **remove** any
> checkbox and you may re-save ones the role already has, but you cannot **add** one your own role
> does not hold. Un-ticking every box is a real state and is saved as "none", not read as "leave
> unchanged".

> **Corner case:** a matrix change can take a while to apply everywhere, and a user moved to a
> different role keeps the old one until they sign in again. Have affected users sign in again; if
> a change still has not applied, ask Epom support or your account manager.

> **Corner case:** the matrix follows your interface language: group, permission and column
> names, the grant options and the Admin UI checkboxes are translated, and so are the headings of
> the two role-editor pages. The role names in the *User Management* group are not — they are
> shown exactly as the role was named.

## Per-role notes

- **Epom support** — the only one who can grant *Manage Role* or add an Admin UI checkbox your
  role lacks; ask them.
- **Other Admin-based roles** — reach the pages their Admin UI checkboxes allow, but their matrix
  has only *User Management* and *Ad Server management*, so no account-level features.
- **Network manager** — manages users from the account-side **Users** page (*User Management
  UI*), handing out only roles it holds **Create** on; cannot edit any role's matrix.
- **Publisher, advertiser** — no user management; an extra login has to come from the network.

## Related

- [Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md)
- [Which permission is missing?](https://epom.com/ad-server/docs/troubleshooting/missing-permission.md)
- [Account users](https://epom.com/ad-server/docs/guides/collaboration/account-users.md)
- [Sharing and permission model](https://epom.com/ad-server/docs/concepts/sharing-permission-model.md)