Create a custom role

This guide shows you how to build a custom admin role with a tailored set of permissions — useful when the built-in system roles don’t match what a specific admin should be able to do.

Who can do this: Admins who have permission to create and manage custom roles.

Before you start

System roles (such as “Read-only” or “Org Owner”) are read-only templates. You start a custom role by cloning one of them.
Role names must be unique across your organization.
Clone opens a short form with Role name pre-filled as the template’s name plus “(copy)”; the custom role is created, with the template’s flags, when you select Save there. Later changes to its name, flags, field categories and Tag bindings are saved separately. A Tag binding can grant it automatically without a manual assignment.
A new custom role, including a clone, can see only General custom fields until you choose more field categories. Cloning doesn’t copy the system role’s categories.
Before binding a Tag, check everyone who already has it: Add binding gives every existing Tag holder this role’s permissions immediately, as well as anyone who receives the Tag later.
A Tag binding is a separate grant with no per-admin scope. A scoped direct assignment cannot narrow permissions the same person also receives through the Tag. If only particular admins should have this role within a chosen scope, skip the Tag binding, assign them individually and set each assignment’s scope with Configure data scope.

Steps

Create and name the role

Go to Roles (at /admin/admin-security/roles).
Under System roles, select Clone beside the template closest to what you need. A form opens with Role name pre-filled as the template’s name plus “(copy)”.
Replace the Role name with a unique name, such as “Events coordinator”.
Select Save. The role is created with the template’s flags.
Check for Role saved. and the new role under Custom roles, then select its name to open the role editor. You can rename it there later with Role name and Save.

Set permission flags

In the role editor, select Flags.
Flags are listed under their category headings, each with its name, description and any Requires: line. There is no search; scroll to the category you need.
Check or uncheck the box beside each flag you want to add or remove.
If a Dependency required warning appears, select Auto-enable dependency to add the required flag, or check it yourself.
Select Save flags. This saves the flag changes separately from the role editor’s Save. Saving does not stop to ask about unresolved dependencies, so resolve any Dependency required warning first.
Check for Flags saved. and the saved selection before binding or assigning the role.

Choose which custom fields the role can see

Every custom field belongs to a field category. Admins with this role see the fields in the categories you check here; fields in other categories are hidden from them, including in exports.

On the custom role editor, find the Field categories section. General is always checked and can’t be removed.
Check each category this role should see, and uncheck any it shouldn’t. You can add only categories your own role includes; you can always remove one.
If your role includes every category (for example, you’re an Org Owner), you have two more options:
- Check All categories, including ones added later to let this role see every category, now and in future.
- To create a new category, type its name in Add a category and select Add. The new category is added to the list, checked. Names are matched exactly, including capitalization.
Select Save field categories. This saves the categories separately from the role editor’s Save.
Check for Field categories saved. before assigning the role.

Optionally bind the role to a Tag

Check the Tag’s current members before continuing. Add binding grants this role to all of them immediately, even if they were not previously admins. This grant has no per-admin data scope; a scoped direct assignment does not narrow it. Skip this section if individual recipients need a restricted scope.

In the role editor, select Bindings.
Choose a Tag in the picker.
Select Add binding. The Bindings screen doesn’t list a role’s existing bindings yet: it keeps showing No group bindings after a binding is added, so the absence of an error is the only sign it was saved. Everyone with that Tag gains this custom role’s permissions immediately; removing the Tag removes those permissions. You cannot bind the Org Owner role this way.

If the picker says No tags available yet, open Members, select a member and add the intended Tag there. Return to the role’s Bindings screen, choose that Tag and then select Add binding. Check the Tag’s other holders before adding the binding: they will receive the role too.

If you bound the wrong Tag, removing that binding isn’t available yet: the Bindings screen can’t list it, so it offers nothing to remove. Removing the Tag from a member ends the permissions that member received through this binding; another direct assignment or Tag binding can still grant the same person permissions.

Assign the role to one admin, with any intended scope

Decide which membership levels, Tags and event categories this admin should reach before you assign the role. Choosing a scope while assigning isn’t available yet: a new assignment starts with no restriction on any axis, so the admin has the role’s permissions across every area from the moment you select Confirm until you save a scope with Configure data scope. Set the scope straight after assigning. Leaving an axis empty means it does not restrict that area. You need permission to manage role assignments, and permission to set their data scope to see Configure data scope.

Under Admins (at /admin/admin-security/admins), select the admin who should hold this role.
On the admin’s Roles tab, select Assign role.
Choose the new role in the picker and select Confirm.
If asked to confirm your identity, complete that challenge before the assignment finishes.
On the admin’s Roles tab, the new assignment shows three scope chips, each not restricted. To restrict it, select Configure data scope on that row, choose Membership levels, Tags and Event categories, and select Save scope. A blank axis narrows nothing in its area; if this role grants event actions, leaving Event categories blank leaves those actions available across events.
Back on the admin’s Roles tab, check the three scope chips on the assignment. Each axis shows its saved choices or not restricted. The same role can have a different scope on another admin’s assignment.

For later changes, open that assignment’s Configure data scope screen, review its three-axis preview and select Save scope. A zero-match warning does not block saving. If Event categories is blank, covered event actions may remain organization-wide; adding categories excludes uncategorized events from this admin’s view. Review the warning before saving.

Scope limits only covered actions, not everything in an area. Some member-addressed billing and giving actions and direct privacy-request actions check levels and Tags, but other actions remain outside these limits; the privacy-request list filter is still being built. A saved scope or the Permissions list is not proof that every action is restricted. For the boundaries and exceptions, see How roles and permissions work.

Sensitive custom fields. Revealing a custom field marked sensitive needs Reveal sensitive field values, and exporting one needs Export sensitive fields. Both are off by default on every role except Org Owner. If you created this role by copying Org Owner before those permissions existed, the copy doesn’t carry them — tick them here if the role should have them.

Verify

The new role appears under Custom roles after you select Save on the Clone form. Check for Role saved., the saved flags on the Flags screen, Field categories saved. and the checked categories in the Field categories section, no error after Add binding (the Bindings screen doesn’t list bindings yet), and all three saved scope chips on the chosen admin’s Roles assignment after Save scope. These are separate outcomes; the Permissions view shows granted flags, not which stored scope checks each operation enforces. If you need to verify a restriction in practice, check an action known to be covered by that scope using the chosen assignee; one covered action does not prove that every operation is restricted.

If something goes wrong

“Role name already in use.” (under Role name) — Another role in your organization already has this name. Enter a different name and select Save again; the Roles list shows the names already taken.
An error appears above Save on the Clone form — No role was created. The form stays open; check the Role name (re-enter it if it changed back) and select Save again.
An error appears above the role name in the editor — Your changes weren’t saved. Check Role name and Description (re-enter any change that was lost), select Save again without cloning again, and wait for Role saved. before setting flags or assigning the role.
Dependency required warning appears — You’ve turned on an action that requires another action. Select Auto-enable dependency or manually enable the required flag before Save flags.
An error appears above the flag list after Save flags — Your selections remain in the flag editor. Select Save flags again and confirm Flags saved. before assigning the role.
“Could not add binding.” (or another error under Add binding) — The binding was not saved; choose the Tag and select Add binding again.
“This tag is already bound to the role” — That Tag already grants this role, so there is nothing to add. (The Bindings screen doesn’t list existing bindings yet.)
Scope save failed — Keep the scope editor open, review the selected axes and try Save scope again. Do not treat the intended scope as active until the assignment’s three chips show it.
“You can only grant field categories your own role includes.” — you checked a category your own admin roles don’t include. Uncheck it, or ask an admin whose role includes it (such as an Org Owner) to grant it.
“Could not save field categories.” — the categories were not saved. Review your choices and select Save field categories again.
The category you need isn’t listed, or there’s no Add a category box — only an admin whose role includes every category can create a category or grant one you don’t have. Ask an Org Owner.
Can’t edit a system role — System roles are read-only. Clone the system role to create an editable custom version.