Sharing and permission model
How roles, permission grants, entity shares and masking combine to decide exactly what each user sees and can change.
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).
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).
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.
