Path: Access → Permissions · URL: /permissions
What this page does
The Permissions page is where you decide what each access group can actually do. This is the single most security-sensitive page in Wazzi — every toggle here is the difference between someone seeing a customer record and not seeing it, between an AI agent being able to send Slack messages on your behalf and being told "no."
Three categories of permissions, top to bottom in the left panel:
- Administration — who can manage Wazzi itself (Users, Groups, Permissions, Connectors, Audit, Settings).
- Centers — per-product access (Operations Center, Knowledge Base, Portfolio Center, Agent Center).
- MCP Connectors — per-connector granular actions for every external tool you've added (Asana, High Level, Slack, etc.).
The most important sentence in this whole guide: regular Users have no access until they're added to a group with permissions turned on. A user with no group memberships, or a user in groups with no permissions flipped on, will sign in to an empty sidebar and won't be able to do anything. Administrators bypass this entirely. See Inviting a User for the role distinction.
How permissions actually work end-to-end
Understanding the flow helps you debug "why can't they X?" questions:
User signs in → Wazzi loads their group memberships
→ Computes the union of permissions across all groups
→ Filters every UI page based on this set
→ Stamps the user's MCP token with this permission set
User opens Claude / ChatGPT / Cursor with their MCP URL
→ AI tries to call a tool (e.g., "create High Level contact")
→ MCP server checks: does this user have ghl.contacts.create?
→ If yes, the call goes through.
→ If no, the AI sees an explicit "permission denied" error
and typically tells the user "I'm not allowed to do that."This is why a user can be "added to a group" but still see nothing: groups have no permissions until you flip them on here.
Worked example: granting MCP read + create on High Level
Let's grant the GHL Users group (created in Creating an Access Group) the most common pattern: read + create permissions on the High Level MCP connector.
1. Click Access → Permissions in the sidebar.
The page opens with the access group selector at the top. Pick the group you want to edit.
The left panel under the selector lists three top-level permission categories. Each expands into sub-categories. A common pattern most orgs follow:
- Keep Administration → Access toggles off for everyone except a small "Operators" group, because they're how you accidentally grant root.
- Use Centers → Knowledge Base for things like "this group can author KB articles" — pair it with a separate KB Owners group that has delete permissions.
- Spend the most time in MCP Connectors — that's where most of the granular work happens.
2. Look at Centers → Knowledge Base.
This is where you decide if a group can create, edit, or delete KB articles, manage portals, change the theme, and so on.
A common pattern is a KB Authors group with create + update on KB but no delete — and a separate KB Owners group with the full set including delete. That way authors can't accidentally remove an article the whole company depends on.
3. Drill into MCP Connectors → High Level.
The MCP Connectors section is the granular one. Each connector lists every action you can grant — viewing contacts, creating opportunities, posting messages, and so on.
What does each toggle actually grant? Every MCP toggle maps 1:1 to a tool call. Toggling "List contacts" on means "the AI agent can fetch contact lists for this user." Toggling "Create opportunity" on means "the AI can create new pipeline records on the user's behalf." If you toggle nothing, the AI sees a connector that exists but has no usable tools — same as if the connector wasn't connected at all from the user's perspective.
Use the All / Read / Create filter tabs at the top of the list to narrow what you're looking at:
- All — every toggle.
- Read —
get_*,list_*,search_*actions. Safe to grant broadly; can't change anything. - Create —
create_*,add_*,post_*actions. Has side effects in the external system. Grant intentionally.
4. Filter to Read, click Enable all Read, then switch to Create and click Enable all Create.
Saving changes
When you flip a toggle, the No changes label in the top-right turns into a Discard / Save changes banner. A small dot appears next to any category with unsaved changes so you don't lose track of where you've been across the navigation tree.
Click Save changes to commit. Changes take effect immediately — no need to ask members to sign out.
Permission patterns by team
Starter recipes; tune to your actual setup.
| Team / Role | What to grant | What to avoid |
|---|---|---|
| Sales / SDRs | MCP Read + Create on CRM (HubSpot, GHL, Salesforce). Read on Slack. | Delete on CRM. Admin → Connectors. |
| Support agents | MCP Read + Create on ticketing (Zendesk, Intercom). Read on KB. | Delete or update on KB without a review step. |
| Engineering | MCP Read + Create on GitHub, Linear, observability tools. Read on Slack. | Centers → Connectors (so they can't add new connectors freely). |
| Read-only Auditor | Read on everything. | Anything that creates, updates, or deletes. Admin → anything. |
| On-call rotation | MCP Create on Slack, PagerDuty. Read on observability. | Persistent membership — rotate users in/out monthly. |
| Vendors / contractors | Bare minimum to do their job. Often a single tool's read access. | Default to nothing; add only as needed. |
Troubleshooting
- A user reports "I can't see any pages." They're a regular User and aren't in a group with Administration → Access or Centers permissions enabled. Confirm group membership in Inviting a User → Access Groups tab, then check the right toggles here.
- An AI agent says "Permission denied" when calling a tool. The user calling the tool doesn't have that specific MCP toggle on. Find the user → which groups they're in → which group should grant the permission → flip it on.
- A user has access through one group but I want to lock them out for a specific surface. Wazzi has no "deny" toggles. Remove them from the group that grants the access (and add them to a more restricted group if needed).
- I flipped a toggle but nothing changed. Did you click Save changes? Pending toggles aren't applied until saved. The banner in the top-right tells you when there are unsaved changes.
- Toggles look greyed out. That category requires a Center to be enabled. See Enabling Centers Products.
Best practices
- Start tight, loosen as needed. Always easier to add a permission than to explain why someone had access they shouldn't have.
- Audit MCP toggles every quarter. Especially Create / Update / Delete on customer-data connectors. The audit log makes this trivial — see Reading the Audit Log.
- Document group → permission intent. The group's Description field on the Groups page is the place to write "this group grants Read + Create on High Level CRM." Future-you will be grateful.
- Avoid "Enable all" outside of Read. Read is broadly safe; Create has side effects on external systems; Update / Delete should be granted granularly with intent.
Frequently asked questions
Can I test what a regular user sees without creating a fake account?
Not yet — coming. For now, create a test User account, add them to the relevant groups, and sign in as them.
Are permissions cached?
Briefly — typically a few seconds. Toggling a permission and immediately calling an MCP tool may hit a stale cache; retry in 5 to 10 seconds.
Do permission changes show up in the audit log?
Yes. Every toggle flip is logged with actor, target group, target permission, and timestamp. See Reading the Audit Log.
Can I export the current permission state?
Not from the UI yet. Available via the Wazzi REST API for scripted audits.
What's next
- See Browsing the Connectors Catalog to check what these MCP permissions let users actually do from Claude / ChatGPT / Cursor.
- Re-read Inviting a User if you need a refresher on the Administrator vs User role split.
- If a category doesn't show up here at all, the corresponding Center isn't enabled. See Enabling Centers Products.