Users, roles and permissions reference

The companion to Manage users, roles and permissions. 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 and Grants for the complete sets and which combinations the editor actually offers.

For how permissions then combine with entity shares, see Sharing and permission model.

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); 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.
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, 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
• Which permission is missing?
• Account users
• Sharing and permission model