Path: Access → Groups · URL: /access-groups
What this page does
An access group is a bundle of permissions. Instead of toggling permissions for each user one by one — exhausting at scale and easy to mess up — you create a group like "Sales (read CRM, send Slack)" once, add users to it, and the group's permissions apply to every member. When the group's permissions change, every member's access updates automatically.
A user can belong to any number of access groups. Their effective permissions are the union of permissions across all groups they belong to. So you can mix-and-match: a sales engineer might belong to Sales (CRM access) plus Engineering (read-only repo access) plus On-call (Slack create access during incidents).
Groups are for regular Users only. Administrators bypass all permission checks — putting them in a group has no effect. If everyone you ever invite is an Admin, you don't need groups at all. Most orgs grow past that point quickly. See Inviting a User for the role distinction.
Common group patterns
The single biggest decision when designing groups is: how do you slice your org? Every org is different, but most settle on one of these patterns or a hybrid:
| Pattern | When it works | Example groups |
|---|---|---|
| By function | Small org, clear team boundaries | Engineering, Sales, Support, Operations |
| By tool / surface | You'd rather think in terms of capabilities | CRM Editors, Slack Posters, KB Authors, Read-only Auditors |
| By project / product line | Multiple distinct products with separate stakeholders | Product Alpha team, Product Beta team, Shared services |
| By seniority / risk level | Heavy compliance environment | L1 Support (read-only), L2 Support (create + update), L3 Support (delete + escalate) |
A common mistake is to start too granular ("one group per micro-permission") — you end up with 40 groups, each with two users, and you've recreated the problem groups were supposed to solve. Start with broad groups, split them when a real-world need emerges (e.g., "we need a read-only auditor variant of Support").
The other common mistake is to start too broad ("one group called Everyone"). That works on day one but turns into a security incident when the first contractor needs access to one thing without access to everything else.
Rule of thumb: if you'd describe a person's job title in 2 or 3 words, that's probably the right shape for a group.
Creating a group
1. Click Access → Groups in the sidebar.
A brand-new org has no groups yet:
2. Click New access group in the top-right.
You'll be taken to a create form with two fields: Name (required) and Description (optional but strongly recommended).
Naming tips. Future-you (and your teammates) will thank you for descriptive names. Compare "Group 1" vs "GHL Users — read + create CRM via MCP". Use a consistent format:
<scope> <intent>. The description field is where you put the why — "what does someone gain by being added to this group?"
3. Fill in the form and click Create Access Group.
You'll see an "Access group created" toast and land on the group's detail page. The detail page has two tabs: Details (rename or change the description) and Members (add users).
Important: the group exists, but at this point it grants no access to anyone — even when you start adding members in the next step. Permissions are flipped on a separate page. See Managing Permissions.
Adding members
1. Click the Members tab on the group's detail page.
2. Click Add User.
A dialog opens listing every user in your org who isn't already in this group. Pending users (invited but not yet accepted) are listed by email, not name.
3. Tick the checkbox next to each user you want to add (or Select all), then click Add Users.
Adding a user to a group takes effect immediately — they don't need to sign out. New permissions show up the next time they reload a page or invoke an MCP tool.
Editing or deleting a group
- Use the Details tab to rename or change the description, then Save Changes.
- The Delete button (top right of the detail page) removes the group entirely. Members stay in the org but lose any permissions that came from this group.
Troubleshooting
- A user I expect to see in the Add User dialog is missing. They're already a member. Look at the existing Members table.
- I added someone to a group but they still can't see things. The group itself has no permissions yet. Visit Managing Permissions. The group → permission mapping is a separate step.
- A user belongs to two groups with conflicting permissions — what wins? Permissions are additive (union), and Wazzi has no "deny" toggles. So most permissive group wins by definition. If you need to remove access, take the user out of the group that grants it — there's no override.
- I deleted a group by accident. Group deletes are recoverable from the audit log within 24 hours — contact your Wazzi administrator. After 24h the deletion is permanent.
Best practices
- One group per role, not per permission. A Sales group with 12 perms is easier to reason about than 12 single-perm groups assigned together.
- Use descriptions liberally. Future-you in 6 months won't remember why this group exists.
- Audit group memberships quarterly. People change roles. The On-call group should match who's currently on call, not who was on call when you created the group.
- Keep an empty Read-only Auditor group around. Useful for security reviews, audits, and onboarding new teammates who need to learn the system without touching anything.
- Don't put Admins in groups. They bypass groups entirely — putting them in adds noise without effect.
Frequently asked questions
Can a single user belong to multiple groups?
Yes — and most do in real-world setups.
How many groups can I create?
There's no hard cap. Practically, more than 20 groups gets unwieldy; consider consolidation.
Can groups have sub-groups (nesting)?
No — Wazzi keeps the model flat on purpose. Use additive memberships instead (a user in Sales + Read-only Auditor gets the union).
Can a group own a connector or a portal?
No — connectors and portals are owned by the org. Groups grant access to them via permissions; they don't own anything.
What's next
- The group exists, members are added — but it still doesn't grant any actual access. Head to Managing Permissions to flip the toggles.
- If you want to see what permissions become available once you wire a connector to this group, check Browsing the Connectors Catalog.
- Need a refresher on Administrator vs User roles? Inviting a User covers it.