---
title: "Sharing and permission model"
description: "How roles, permission grants, entity shares and masking combine to decide exactly what each user sees and can change."
type: "concept"
audience: [network-manager, admin]
keywords: [roles, permissions, grants, all, shared, read-only, is owner, can edit, can view, masked, statistic account, default share]
ui_path: "Admin → Users & access → User roles & permissions"
---

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.

# Sharing and permission model

Two independent systems decide what a user can do. **Permissions** (attached to the user's
role) answer "which features and entity types, and how deep". **Shares** (attached to
individual entities) answer "which *specific* advertisers and sites". The UI you see is
always the intersection of the two. This page explains each layer and how they combine.

## Layer 1 — roles

Every user has exactly one role. A role is built on one of the platform's static base
roles (admin-level or account-level), which fixes its general shape, and then carries its
own permission matrix. Network administrators create as many custom roles as they need — "Publisher",
"Advertiser", "Ad Ops", "Client read-only" are all just roles with different matrices
([Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md)).

There are no per-user permission matrices to maintain: change a role and everyone in it
changes with it.

## Layer 2 — the permission matrix

The matrix is a long list of named permissions, each set to one of a small set of
**grants**. Three grant families cover almost everything:

| Grant family | Values | Used for |
|---|---|---|
| Entity scope | **None / All / Shared** | Entity-type permissions: Inventory (sites, zones, placements), Campaigns (advertisers, campaigns, banners), Templates, Actions. *All* = every entity in the network; *Shared* = only entities shared to the user; *None* = the area disappears. |
| Feature toggle | **Enabled / Disabled / Read-only** | Feature permissions: each targeting dimension, capping, pricing, weights, auto-linking, and hundreds more. *Read-only* shows the card with all controls disabled. |
| View style | e.g. Trees / Grids, report depth levels | A few presentation permissions (navigation style, analytics report complexity). |

Entity permissions additionally split by operation — view, create, update, delete, share —
so a role can, say, view all inventory but create nothing.

Admin-capable roles have one extra section: a checkbox list of **admin pages**, each
checkbox one page of the Admin area. There is no per-ad-unit or per-partner grant in the matrix:
which ad units and DSP partners a user can pick follows the feature permission (for example
**Open RTB** for programmatic banners), not a list of allowed entries.

### How the UI applies it

The interface derives itself from the matrix: a permission at *None*/*Disabled* removes
the card, tab, or menu item entirely; *Read-only* renders it with controls disabled; the
entity-scope grants decide whose data populates every grid and tree. All of this is
computed on the server — what the browser gets is already filtered.

> **Corner case:** permission changes are not always instant. A role change can take a while to
> reach every user, and the account UI re-reads the user's permissions at most every five minutes.
> Allow for that before concluding a grant "doesn't work", and have the affected user reload the
> page; if it still has not applied, contact Epom support or your account manager.

## Layer 3 — entity shares

Shares connect one user to one advertiser or one site (plus templates and conversion
actions), each with a level:

```
Is Owner  ⊃  Can Edit  ⊃  Can View
```

| Level | The recipient can |
|---|---|
| **Is Owner** | Everything, including sharing the entity on up to *Is Owner*. Creating an advertiser or a site makes you its owner. |
| **Can Edit** | View and change the entity and its children. May also share it on, up to *Can Edit*, when their role holds the **Share** permission. |
| **Can View** | Open everything read-only; run statistics. No saves, and no sharing. |

A share covers the whole subtree: sharing an advertiser includes its campaigns and
banners; sharing a site includes its zones and placements.

Each user also keeps a list of **default sharing settings** (Account → Preferences): users who
automatically receive a share, at the type you pick, on every site, advertiser, template and
conversion action that user creates from then on. It is not a level assumed for entities
without a share — at creation time each entry becomes an ordinary share row, which is how "give
this manager Can Edit on everything I create" is expressed without clicking through each new
entity. **Apply to existing entities** pushes the list onto what the user already owns.

### How grants and shares combine

The entity-scope grant picks the *universe*; the share picks the *depth*:

- **All** + any shares → the user sees every entity; shares only matter for ownership
  semantics (e.g. who may manage sharing).
- **Shared** → the user sees exactly the entities shared to them, each at the depth of its
  share type. This is the standard client setup: a publisher is a user with Inventory=Shared
  plus *Is Owner* shares on their sites.
- **None** → the area is gone; shares to it are moot.

## Read-only vs masked

Two distinct "can't touch" experiences, often confused:

- **Read-only from a Can View share**: the entity's edit page shows its fields read-only and
  has no Save, and statistics stay fully available. The name is not marked in lists — a Can View
  entity looks like any other. The data is real; you just can't change it. A few buttons outside
  the form, such as **Delete** in the Publishers tree, are not greyed out, and the server refuses
  what they ask for.
- **Masked**: when the user's role holds the *Mask Inventory* or *Mask Campaigns* permission,
  every site or advertiser the user does not own is shown under an anonymized codename
  (e.g. `ADVERTISER_123`, `SITE_456`) with contact fields blank. The substituted name is the
  signal: only the advertisers grids also set it in grey *italics* (the entity trees show it in
  ordinary type). Italics therefore mean **masked**, never "read-only".
  Masking hides *identity*, not existence — the masked party still sees volumes and revenue.
  This is how a client can run campaigns across your inventory without learning which sites they
  run on.

The two are independent: a masked entity can be editable, and a Can View entity is
usually unmasked.

## Statistic accounts

A statistic account is not a separate mechanism — it's the same model in its minimal
configuration: a user whose role grants little beyond analytics, holding a *Can View*
share on one entity. The **Create user & share** action on advertiser and site edit
pages (its dialog is titled **Create statistic account**) builds exactly that in one step and
emails an invitation with a single-use set-password link
([Share sites and advertisers](https://epom.com/ad-server/docs/guides/collaboration/shares.md)).

## Corner cases and gotchas

> **Corner case:** shares grant access, but the *role* still rules. A Can Edit share does
> nothing for a user whose role has the relevant area at None, and a feature the role has
> Disabled stays hidden even on entities the user owns. When someone "can't see what was
> shared", check the role matrix first.

> **Corner case:** sharing is bounded, so access cannot quietly escalate through a chain of
> recipients. A role with **Share** at *all* width may change any share. At *shared* width the
> caller must hold *Can Edit* or *Is Owner* on that very entity, can grant at most their own
> share type, cannot replace or remove a share above their own (the owner's), and the only
> exception is a user they created themselves. A refused change answers 403, naming the
> permission.

> **Corner case:** the role editor cannot be used to mint rights its user does not hold. It
> refuses to edit a role the editor may not manage, refuses grants over a role the editor may not
> manage (and *Manage role* itself, which only Epom support grants), and lets an editor *add*
> only admin pages from their own set — removals and a plain re-save pass through.

## Related

- [Manage users, roles and permissions](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md)
- [Share sites and advertisers with users](https://epom.com/ad-server/docs/guides/collaboration/shares.md)
- [Account users](https://epom.com/ad-server/docs/guides/collaboration/account-users.md)
- [Role playbooks](https://epom.com/ad-server/docs/roles/network-manager.md)
- [Demo accounts](https://epom.com/ad-server/docs/roles/demo-account.md)