MemberPass
Teams & Roles

Groups

Define ad-hoc permission collections, attach specific members to them, and layer extra access on top of roles.

By the end of this page, you'll know when to use groups over roles, how to create them, and how to attach specific team members to a group for one-off access needs.

Groups live at Settings → Groups (URL: /settings/groups). A group is a name plus a set of permissions plus a specific set of members — all three together.

Why groups?

Roles answer "what can this kind of person do?" — great for stable job descriptions. Groups answer "what can these specific people do for this specific purpose?" — great for temporary teams, special projects, or permissions that cut across role boundaries.

Temporary project teams

A handful of collaborators pulled together for a three-month push (e.g. "Q4 Launch Team"). They already have their regular roles; you just need to temporarily grant create access codes so they can set up promo codes. A group handles that cleanly — create it, add the people, grant only what they need, delete the group when the push ends.

Accountant or auditor access

Your external bookkeeper needs read-only access to payments during tax season. Create a group with just project-subscription:view-any and project-user:view-any, drop them in, and remove them when the audit is done. No need to invent a custom role that only one person will ever use.

Founders or core team

A small circle that needs blanket access across everything. Simpler than creating a maximalist role and assigning it one-by-one — one group with all permissions ticked, add whoever should be in it.

Create a group

Open Groups Settings.

Go to Settings → Groups (URL: /settings/groups). The page shows all groups for your current team.

Click Create group.

A modal appears.

Fill in the group's details.

  • Name — A human-readable label, e.g. "Q4 Launch Team". Up to 255 characters.
  • Code — A machine-friendly identifier, e.g. q4-launch-team. Letters, numbers, dashes, and underscores only (alpha_dash). Must be unique within the team.
  • Permissions — Tick the permissions this group grants its members. Same 35-permission picker you see for roles — see Ability reference.

Click Save.

The group appears in your team's group list. A toast confirms: "Group created successfully."

Add members to a group

A group without members grants nothing. After creating a group, add the people who should inherit its permissions.

On the Groups page, find the group and click its Members (people) icon or button.

A modal appears with a checklist of your team's current members.

Tick every member who should belong to this group. Untick anyone who shouldn't.

Click Save in the modal.

A toast confirms: "Group members updated successfully." Members picked up the group's permissions on their next page load.

A member can be in many groups at once — permissions from all their groups add up with their base role permissions. There's no subtraction: groups can only grant additional access, never revoke it.

Edit a group's permissions or name

On the Groups page, click Edit next to the group.

Update the name or tick/untick permissions. The code is set at creation and stays fixed.

Click Save. Members of the group see their effective permissions update on the next request.

Delete a group

On the Groups page, click Delete next to the group.

Confirm. The group is removed and a toast confirms: "Group deleted successfully."

Only the team owner can delete groups. Members without this privilege will see an "Unauthorized" toast. That's deliberate — groups often carry sensitive permissions, and deleting one without warning could strand collaborators.

Deletion does not affect the members themselves — they keep their base role and any other groups they belong to. They just lose the permissions the deleted group was granting.

Roles vs. groups: quick recap

  • Roles are 1:1 with members: each person has exactly one role.
  • Groups are many-to-many: a person can be in many groups, and each group can have many people.
  • Both can grant the same 35 permissions — they differ in application style, not vocabulary.

Use roles first for stable permissions, add groups when roles don't capture the shape of what you need.

Common questions

  • Roles — the primary permission tool; start here before groups.
  • Ability reference — full permission list with descriptions.
  • Invite members — put people in the team in the first place.

On this page