Skip to main content

Permissions

The platform controls who can do what via a hierarchical permission tree. Each permission is a node like Pages.Loyalty.Members.GdprErase; granting it to a role lets users in that role perform the action.

When this matters to you​

  • You're setting up a new role for a junior admin and need to know which permissions to grant.
  • A user reports they "don't see a menu entry" — usually a missing permission.
  • You're integrating with the platform and want to know what an API token needs.

Top-level groups​

The tree is organised by feature area. Top-level branches:

BranchCovers
Pages.AdministrationRoles, users, languages, audit logs, organization units, customisation, API keys, webhooks, infrastructure monitoring.
Pages.Loyalty.*Programs, members (+ GDPR sub-permissions), transactions, tiers, rewards, coupons, referrals, segments, gift cards, paid memberships, family pooling, auctions, NPS, cashback, products.
Pages.Gamification.*Games (built-in + external definitions), campaigns (+ winners, winning moments), challenges, badges, leaderboards, streaks, advent calendars, A/B tests, treasure hunts.
Pages.Communications.*Channels, templates, messages, flows, Meta health, broadcasts, email campaigns.
Pages.Surveys.*Surveys (+ Create/Edit/Delete).
Pages.DynamicLinks.*Short links (+ Domains).
Pages.PinCodesPIN-code campaigns.
Pages.Partners.*Partner tenant management (gates impersonation too).
Pages.SocialListeningSocial listening sources and mentions.
Pages.CreditBalanceCredit-system metering for paid features.

How permission reconciliation works​

When a new release adds a permission node (e.g. Pages.Communications.MetaHealth.Refresh), it needs to be registered in code and made available to your roles. The platform runs a reconciler on startup that:

  1. Reads the current set of declared permissions from code.
  2. Compares against the database.
  3. Adds missing nodes; warns about nodes in the database that are no longer declared.

This means upgrades don't require a manual SQL step to make new permissions available — they appear in the role management UI automatically. (A pre-push gate also catches the case where someone declares a permission constant but forgets to register it — see the platform's developer docs.)

Step-by-step​

See what a role can do​

  1. Go to Administration → Roles.
  2. Open the role.
  3. The Permissions tab shows the tree with the checked nodes — that's exactly what the role can do.

Create a curated role​

  1. Go to Administration → Roles → Create role.
  2. Name it (e.g. Marketing Manager).
  3. Tick the permissions the role needs. Use the search box to find specific nodes.
  4. Save.
  5. Assign users to the role under Administration → Users.

Add granular permissions​

Some features are gated by multiple permissions so you can grant view but not write. For example:

  • Pages.Communications.MetaHealth — view the health page.
  • Pages.Communications.MetaHealth.Refresh — also trigger a refresh probe.

Grant the parent without the sub-permission for read-only access.

The PartnerAdmin role​

Partner impersonation (see Tenant impersonation) uses a separate, smaller permission set defined in PartnerAdminPermissions. It's a deliberately curated subset of the tenant-side tree — excluding user management, billing, and API-key administration — so that an impersonating partner cannot escalate inside the tenant. This role exists alongside the standard ABP role tree but is not editable in the UI.

Limits and gotchas​

  • Menu items hide on missing permissions. A user with no permission for Surveys won't see the Surveys menu entry. That's a feature, not a bug — but it also makes "I can't see X" tickets common. Check permissions first.
  • Permissions reconcile on app startup. A node added in a release appears after the next deploy, not immediately.
  • Sub-permissions imply the parent. Granting Pages.Loyalty.Members.GdprErase without Pages.Loyalty.Members is non-functional — the user can't reach the page that hosts the button.
  • Per-tenant feature gates are separate from permissions. A permission lets a role do an action; a feature flag lets a tenant see it at all. Both must be on.