Permission flags reference
This page lists every permission flag available in the MapleGather custom role editor, grouped by the nine categories the editor uses, plus the dependency and data-scope rules that govern them.
This is a complete list, not a selection. The editor offers 88 flags across 9 categories, and all 88 are below. If you find a flag in the editor that does not appear here, this page is behind the product — please tell us.
How to read a row. Each row gives the flag’s name and its description exactly as the role editor shows them, the flag’s key — the short identifier the editor uses in its own Requires: line — and the flags it requires. A key names the flag. For most flags it is also the name of the internal permission that flag grants — but not for all of them, which is what the next two sections are about.
A flag key is not the same thing as an internal permission. Flag keys and MapleGather’s internal permission names are written the same way and often read the same, but they are two vocabularies and they do not line up one-to-one. MapleGather uses more internal permissions than the role editor exposes as flags: for example, events:view is a real permission inside MapleGather but is not a flag you can switch on; the flag that grants event access is View events (events:read). Only the 88 flags below can be turned on or off in a custom role.
Read a key as a name, not as a promise. A handful of flags grant internal permissions whose names differ from the flag’s own key — what a flag grants is better read from its What it allows column — the editor’s own description — than guessed from the key. Treat that column as the plain-English summary rather than an exhaustive list: a few flags grant slightly more than it spells out. reports:view is the clearest example — it is described as viewing dashboards and saved results, and it additionally carries the permission to run a report. The key is there so you can recognise the flag in the editor’s Requires: line and in a role’s saved definition.
Flag categories and flags
Section titled “Flag categories and flags”Members (10 flags)
Section titled “Members (10 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Override member consent preferences | consent:write |
Override a member’s email and communication consent preferences on their behalf. | — |
| Configure custom member fields | custom_fields:write |
Create, edit, and remove the custom field definitions on the member record. | — |
| View the directory privacy audit | member:view-privacy-audit |
View the directory privacy audit showing which fields each member exposes. | — |
| Bulk member actions | members:bulk-write |
Apply bulk edits, tags, or status changes across many members at once. | members:read |
| View members | members:read |
View the member roster and individual member records. | — |
| Change who can sign in at a household level | members:revoke-account |
Switch a household level between every-member sign-in and owner-only sign-in, and undo a switch within 48 hours. Linked members who lose sign-in keep their records. | memberships:write |
| Create & edit members | members:write |
Create new members and edit existing member records. | members:read |
| Reveal sensitive field values | members:read-sensitive |
Reveal the value of a custom field marked sensitive on a member record. Every reveal is recorded in the audit log. | members:read |
| Export sensitive fields | members:export-sensitive |
Include custom fields marked sensitive in a member export. The export is recorded in the audit log. | members:read |
| Create & edit tags | tags:write |
Create, rename, and delete the tags used to segment members. | — |
Change who can sign in at a household level works with Edit levels & process applications. Changing the sign-in setting on an existing household level needs both flags. Creating a new household level with owner-only sign-in needs only Edit levels & process applications. Undoing a switch also needs permission to reverse recent admin changes. See Family and household level settings reference.
Off by default. Only the Org Owner role has Reveal sensitive field values and Export sensitive fields out of the box. Every other role — including Membership Manager, even though it manages members fully — gets them only when you tick them. A custom role you copied from Org Owner before these permissions existed doesn’t have them: open the role and tick them if it should.
Memberships (2 flags)
Section titled “Memberships (2 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| View memberships & applications | memberships:read |
View membership levels, active memberships, and the application queue. | — |
| Edit levels & process applications | memberships:write |
Edit membership levels and approve, reject, or activate applications. | memberships:read |
Events (16 flags)
Section titled “Events (16 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Cancel events | events:cancel |
Cancel a published event and trigger the resulting registration refunds. | events:read, events:write |
| Check in attendees | events:check-in |
Check attendees in at an event. | events:read |
| Undo a check-in | events:check-in-undo |
Reverse an attendee check-in recorded in error. | events:read |
| Edit events, tickets & sessions | events:edit |
Edit an event’s details, tickets, and sessions. | events:read |
| Configure automated event emails | events:edit-emails |
Create, edit, and delete the automated email rules that fire for an event. | events:read |
| Edit registrations | events:edit-registration |
Edit an existing attendee registration. | events:read |
| Export the attendee list | events:export-attendees |
Export the attendee list for an event. | events:read |
| Export sensitive attendee fields | events:export-sensitive-fields |
Include sensitive attendee fields in an event export. | events:read |
| Manage event categories | events:manage_categories |
Create, rename, and delete the categories events are filed under. | events:read |
| Message attendees | events:message-attendees |
Send messages to an event’s registered attendees. | events:read |
| Move registrations between events | events:move-registration |
Move a registration to a different event and reconcile the payment difference. | events:read |
| View events | events:read |
View events and their registrations. | — |
| Register attendees on their behalf | events:register |
Register a member for an event, or place a multi-ticket order, on their behalf. | events:read |
| View the attendee list | events:view-attendees |
View an event’s registrations, attendees, and multi-ticket orders. | events:read |
| Promote from the waitlist | events:waitlist-promote |
Manually promote a waitlisted registration into a confirmed place. | events:read |
| Create & publish events | events:write |
Create and publish new events. | events:read |
Billing (20 flags)
Section titled “Billing (20 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Configure the payment processor | billing:configure-processor |
Connect and configure the organization’s payment processor. | billing:read-processor |
| View the dunning policy | billing:read-policy |
View the dunning (failed-payment retry) policy. | — |
| View payment-processor settings | billing:read-processor |
View the payment-processor connection settings. | — |
| Manage billing (create subscriptions) | billing:write |
Manage billing, including creating member subscriptions. | — |
| Edit the dunning policy | billing:write-policy |
Edit the dunning (failed-payment retry) policy. | billing:read-policy |
| Delete invoice templates | invoice_templates:delete |
Remove an invoice template from the org’s template library. | invoice_templates:read |
| View invoice templates | invoice_templates:read |
View the reusable invoice templates used to bill members. | — |
| Create & edit invoice templates | invoice_templates:write |
Create new invoice templates and edit their line items and branding. | invoice_templates:read |
| View invoices | invoices:read |
View member invoices, their line items, and payment status. | — |
| Create, edit & void invoices | invoices:write |
Create member invoices, edit their line items, and void mistaken ones. | invoices:read |
| Resend payment receipts | payment_receipts:write |
Resend payment receipts to members. | — |
| Export payments | payments:export |
Export payment records. | payments:read |
| View payments | payments:read |
View payment records and transaction history. | — |
| Record manual payments & refunds | payments:write |
Record manual payments and issue refunds. | payments:read |
| Charge a card on file | payments:write-admin-charge |
Charge a member’s card on file. | payments:read |
| View receipt templates | receipt_templates:read |
View the receipt templates sent to members after a payment. | — |
| Create & edit receipt templates | receipt_templates:write |
Create receipt templates and edit their content and branding. | receipt_templates:read |
| Decide refund requests | refund_requests:write-admin |
Approve or deny member refund requests. | — |
| Cancel the Browncoat subscription | subscription:cancel |
Cancel the organization’s own Browncoat subscription. | — |
| Pause, resume & cancel subscriptions | subscriptions:write |
Pause, resume, and cancel member subscriptions. | — |
About “Browncoat”. Browncoat is MapleGather’s internal platform name, and one flag above still carries it. “Cancel the Browncoat subscription” means your organisation’s own MapleGather subscription — the one you pay us for — not a member’s subscription to your organisation. The two are separate flags.
Email (9 flags)
Section titled “Email (9 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Cancel broadcasts | email:cancel-blast |
Cancel an email broadcast that is scheduled or sending. | email:read |
| Configure the double-opt-in policy | email:configure-opt-in |
Configure the double-opt-in policy for email subscriptions. | email:read |
| Edit lifecycle templates | email:edit-lifecycle-template |
Edit the automated lifecycle email templates. | email:read |
| View campaigns & templates | email:read |
View email campaigns and templates. | — |
| View deliverability | email:read-deliverability |
View email deliverability metrics and domain health. | — |
| View saved segments | email:read-segment |
View saved audience segments. | — |
| Save & delete segments | email:save-segment |
Save and delete audience segments. | email:read-segment |
| Send email broadcasts | email:send-blast |
Send an email broadcast to a segment or the full list. | email:read |
| Verify deliverability & rotate DKIM | email:verify-deliverability |
Verify deliverability and rotate DKIM signing keys. | email:read-deliverability |
Directory (4 flags)
Section titled “Directory (4 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Create & edit directories | directory:configure-instance |
Create and edit member directories. | directory:view-config |
| Configure privacy defaults | directory:configure-privacy-defaults |
Configure the default privacy settings for directory listings. | directory:view-config |
| View the directory in admin mode | directory:view-admin-mode |
View the directory in admin mode, including hidden entries. | — |
| View directory configuration | directory:view-config |
View the directory configuration. | — |
Admin (14 flags)
Section titled “Admin (14 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Impersonate (preview as a member) | admin:impersonate |
Preview the app as a member (impersonation). | — |
| Edit admin settings & roles | admin:write |
Edit admin settings and custom roles. | — |
| Create & reverse admin overrides | admin_overrides:write |
Apply audited admin overrides (e.g. activate without payment) and reverse them. | — |
| Account handover | admin_users:handover |
Transfer account ownership to another admin (account handover). | — |
| Invite admins | admin_users:invite |
Invite new admins to the organization. | — |
| Manage role assignments | admin_users:manage_roles |
Assign and unassign roles for admins. | — |
| Revoke admin access | admin_users:revoke |
Revoke another admin’s access. | — |
| View effective permissions | admin_users:view_effective_permissions |
View an admin’s effective (role-resolved) permissions. | — |
| View the audit log | audit_log:read |
View the audit log of admin and system actions. | — |
| Sign the DPA | compliance:sign_dpa |
Sign the Data Processing Agreement on the organization’s behalf. | — |
| Start a data import | imports:create |
Start a new data import. | imports:read |
| View imports | imports:read |
View data imports and their status. | — |
| Edit & undo imports | imports:write |
Edit and undo data imports. | imports:read |
| Send a migration claim-account broadcast | migration:broadcast |
Send a migration claim-your-account broadcast to imported members. | — |
Integrations (7 flags)
Section titled “Integrations (7 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| View API keys | api_keys:read |
View the org’s API keys and their scopes (never the secret value). | — |
| Create, rotate & revoke API keys | api_keys:write |
Issue new API keys, rotate existing ones, and revoke compromised keys. | api_keys:read |
| View integrations | integrations:read |
View connected integrations. | — |
| Disconnect integrations | integrations:write |
Disconnect a connected third-party integration from the organization. | integrations:read |
| View webhooks | webhooks:read |
View webhook endpoints and delivery history. | — |
| Replay webhook deliveries | webhooks:replay |
Replay past webhook deliveries. | webhooks:read |
| Create & test webhooks | webhooks:write |
Create and test webhook endpoints. | webhooks:read |
Reports (6 flags)
Section titled “Reports (6 flags)”| Flag | Flag key | What it allows | Requires |
|---|---|---|---|
| Export reports | reports:export |
Download report results as files for use outside the app. | reports:view |
| Export reports with PII | reports:export-pii |
Export reports that include per-member PII. | reports:view-pii |
| Run reports | reports:run |
Run reports on demand. | reports:view |
| View reports & dashboards | reports:view |
View the reporting dashboards and saved report results. | — |
| View the board dashboard | reports:view-board |
View the board-level summary dashboard of organization health metrics. | — |
| View per-member PII in reports | reports:view-pii |
View per-member PII within reports. | reports:view |
Dependency rules
Section titled “Dependency rules”Some flags require other flags to be meaningful. The Requires column above lists every dependency the editor knows about — there are no others. The editor warns you; it does not stop you saving.
If you enable a flag without its dependency, the role editor shows an inline warning naming the missing flag and offers an Auto-enable dependency action. For example:
- “Cancel events” requires both “View events” and “Create & publish events.”
- “Edit levels & process applications” requires “View memberships & applications.”
Accept the auto-enable, or turn the prerequisite flags on yourself. Nothing blocks Save flags if you do neither — the role saves with the gap still in it, which is why the warning is worth acting on.
Data scope (role-assignment filter)
Section titled “Data scope (role-assignment filter)”A role assignment can be scoped to specific values of Membership Level, Tag, or Event Category.
A data scope narrows some areas, not everything. Membership Level and Tag narrow members, memberships and the directory; Event Category narrows events, and every event’s attendees and registrations. Everything outside those areas is unrestricted — billing, email, admin, integrations, reports, donations and website form submissions among them. A scoped role holder still sees all of those, organisation-wide.
And not every action inside a narrowed area is covered. Editing members, editing tags, and viewing the directory privacy audit are not restricted by a data scope. It is not a reads-only limit either: approving or rejecting an application, cancelling a membership, changing a member’s level, and creating a member export are all restricted by the scope. Treat it as narrowing much of what a role reaches in those areas, not as a boundary on everything it can do.
How out-of-scope records behave depends on how they are reached. In lists and searches, out-of-scope records are filtered out rather than raising an error. But opening an out-of-scope record directly — from a saved link, for example — and any action on the attendees or registrations of an out-of-scope event, are refused with a permission error.
Data scope is set at assignment time, not at role-definition time. The same role definition can be assigned to different admins with different scopes.
Group binding
Section titled “Group binding”A role can be bound to a Tag. Any admin who holds that Tag automatically holds the role’s permissions. The binding is dynamic: permissions change whenever Tag membership changes.