How roles and permissions work

MapleGather’s roles let volunteer and professional admins grant different actions inside your organization — from full ownership down to read-only access.

The short version

An admin can hold one or more roles; their effective permissions are the union of the roles they hold. An admin with no assigned roles can sign in but has no admin permissions. Roles start from predefined system templates you can use as-is or clone and customize. You can also narrow an assignment’s reach to specific membership levels, member tags, or event categories. Separately, each role lists the custom-field categories its admins can see.

How it works

MapleGather’s access model works along three axes.

Axis 1 — Predefined system templates

The roles design includes seven read-only templates. Org Owner and Read-only are available in the Roles list now; the other five are planned and may not appear yet:

Template	Typical use	Availability
Org Owner	Full access, including billing and admin management	Available now
Finance Manager	Billing, payments, and financial reports	Planned
Communications Manager	Email, announcements, and directory	Planned
Events Manager	Event creation, check-in, and event reports	Planned
Web Editor	Public-facing pages and branding	Planned
Membership Manager	Member records, membership levels, and renewals	Planned
Read-only	View access across all areas	Available now

These templates are provided by MapleGather and cannot be edited. Clone a template that appears in your Roles list to create a customizable version. The five planned templates remain part of the seven-role design; they are not available to select yet.

Axis 2 — Custom role composition

Clone any template and then add or remove individual permission flags across nine categories:

Members — view, edit, and manage member records
Memberships — manage membership levels and renewals
Events — create, edit, and manage events
Billing — manage payment methods, invoices, and subscription
Email — send and manage email communications
Directory — view and manage the member directory
Admin — invite, edit, and revoke admin accounts
Integrations — connect and manage third-party integrations
Reports — view and export reports

Each flag controls a specific action. You can mix and match flags freely within a custom role.

Axis 3 — Data scope

Optionally set a data scope on each role assignment to specific membership levels, member tags, or event categories. The same role can have a different scope for each admin. An axis left empty narrows nothing in its area.

For example, an assignment with Tag: Boston chapter and Event categories: Workshops can narrow covered member actions to Boston-tagged members and covered event actions to Workshop events. If Event categories is left empty, the Tag does not narrow the events area: any events permission that role grants can still reach events across the organization. Conversely, selecting categories excludes uncategorized events from a category-scoped admin’s view. Choose the intended axes in the Assign role dialog before granting the assignment; review its three scope chips afterward.

What the axes narrow. Membership levels and Tags limit certain actions on members, memberships and the directory. Event categories limit certain event actions, including work with attendees and registrations. Updating a named member is among the actions that check scope. Seven actions on a named member’s billing or giving record also check the selected levels and Tags: a saved-card charge, an account-credit adjustment, four saved-card actions and a giving-summary read. Three receipt actions check them too: resending a payment receipt, viewing a payment’s receipt and resending a donation receipt. They check the member the payment or gift belongs to — for an applicant’s payment, their membership application — so an admin limited to some levels or Tags can’t view or resend a receipt for someone outside them. The donations list and a donation’s page still show such a gift, but without its tax receipt link or receipt number, and so do marking it thanked (or undoing that), refunding it, and a member’s giving summary. A payment or gift with no member record behind it (for example, a guest donation) isn’t limited.

Where the limits remain. Those seven checks have exceptions. (Viewing a payment’s receipt and resending a donation receipt have no such exception: an admin is refused even for their own receipt when their own member record is outside their scope.) An admin-only saved-card charge can still go through when the member is the admin themself, even if that member is outside the admin’s assigned scope. The four saved-card actions also do not yet make all the separate checks required when an admin acts using their own member access. Other billing and donation actions remain outside these checks — for example viewing a single payment or a single donation, and the payment and donation lists — as do many email, integration, report and website-form-submission actions. Even within otherwise limited areas, some actions remain unrestricted by data scope, such as editing Tags and viewing a member’s directory privacy audit. Role permissions still govern whether an action is available at all.

How refusals appear. A list or search covered by data scope leaves out records beyond your assignment. Opening a protected record directly can show a permission error, as can working with an out-of-scope event’s attendees or registrations. Direct reads, previews and deletion decisions for privacy requests check the assigned scope. Filtering the administrator’s privacy-request list is still being built, so a row’s appearance alone does not mean you can open or act on it.

Effective permissions

An admin’s effective permissions are the union of all roles they hold. If one role excludes an action and another includes it, the inclusion wins. You can review any admin’s combined permission flags from Admins (at /admin/admin-security/admins) → select an admin → Permissions tab. That view does not tell you which stored assignment scopes are enforced for each operation; inspect each assignment’s Roles tab for the saved axes and their limits.

Field categories

Permissions decide what an admin can do. Field categories decide which custom fields they see while doing it. Every custom field belongs to one category (General by default), and every role lists the categories its admins can see:

General is always included, so every admin sees General fields.
An admin’s categories are the union of their roles’ categories, the same way permissions combine.
A category no role includes stays hidden from everyone except admins whose role includes every category.
Org Owner includes every category, including ones added later. Read-only includes General only. Of the planned templates, Finance Manager is set to Finance, Communications Manager to Comms and Events Manager to Events; the others are set to General.
A custom role starts with General only. You choose its other categories in the role editor’s Field categories section.

A field in a category an admin’s roles don’t include is hidden from that admin on member and organization records, in the custom field list and in exports. On a record, a line such as “+ 2 fields hidden by your role” shows how many fields are hidden.

You can give a role only the categories your own roles include, and only an admin who sees every category can create a new category. That way no admin can grant access they don’t have. Categories are your organization’s own names, matched exactly.

Field categories are set per role, not per assignment: the data scope you set on an assignment narrows which members an admin reaches, while the role’s field categories decide which fields they see.

Group bindings

You can bind a custom role to a Tag. A person who holds that Tag immediately receives the custom role’s permissions, without waiting to be promoted to admin or for a manual assignment. Removing the Tag removes the binding’s permissions. This is useful for committee-based volunteer organizations where roles follow a position. The built-in Org Owner role cannot be bound to a Tag.

Why it works this way

Small volunteer organizations often need one or two admins who can handle everything. Larger organizations need tighter controls to separate financial, communications, and membership duties. The three-axis model serves both: assign a system template for simplicity, then add custom roles and data scopes as your governance needs grow.

Edge cases & boundaries

An archived role’s existing assignments remain valid until you manually remove them.
An admin with no roles assigned has no permissions — they can sign in but see nothing.
MapleGather prevents any action that would leave your organization with zero Org Owners. Revoking or demoting the last Org Owner is blocked with a clear error message; an Org Owner group binding cannot be created.
SSO claim-based group bindings are planned for a future release.
Fulfilling a member’s request for a copy of their own data includes all of that member’s custom field values, whatever their categories.