Role-Based Permissions in Appalix
Appalix enforces permissions at every layer of the UI — not just in a settings page. Viewers see data but cannot change it. Members work freely within their scope. Admins and Owners control the platform. This guide maps exactly what each role can and cannot do, section by section.
The four roles — a quick recap
Owner
1 per workspace. Full control including billing and deletion.
Admin
Manage bots, integrations, and team. Cannot access billing.
Member
Full CRM/pipeline access. Cannot configure bots or invite.
Viewer
Read-only. Can see everything, change nothing.
Contacts (Sage CRM)
The contacts table is the core of Sage CRM — names, emails, company info, assigned reps, and deal values.
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| View contacts table | ✓ | ✓ | ✓ | ✓ |
| Search & filter contacts | ✓ | ✓ | ✓ | ✓ |
| Open contact detail | ✓ | ✓ | ✓ | ✓ |
| Create new contact | ✓ | ✓ | ✓ | — |
| Edit contact fields | ✓ | ✓ | ✓ | — |
| Assign contact to rep | ✓ | ✓ | ✓ | — |
| Delete contact | ✓ | ✓ | ✓ | — |
| Export contacts | ✓ | ✓ | ✓ | — |
Pipelines
The Pipelines section covers both the pipeline list page (create/delete pipelines) and the kanban/list board inside each pipeline (manage stages, add deals, drag cards).
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| View pipelines list | ✓ | ✓ | ✓ | ✓ |
| Open pipeline board | ✓ | ✓ | ✓ | ✓ |
| View deals on board | ✓ | ✓ | ✓ | ✓ |
| Create pipeline | ✓ | ✓ | ✓ | — |
| Delete pipeline | ✓ | ✓ | ✓ | — |
| Manage stages | ✓ | ✓ | ✓ | — |
| Add deal (opportunity) | ✓ | ✓ | ✓ | — |
| Edit deal | ✓ | ✓ | ✓ | — |
| Drag deal to new stage | ✓ | ✓ | ✓ | — |
| Change stage (list view) | ✓ | ✓ | ✓ | Read-only label |
Viewers see the pipeline board in full but all interactive controls (drag handles, stage selects, add-deal button, edit pencils) are hidden or replaced with read-only equivalents.
Tickets
The Tickets section surfaces support requests, bug reports, or any work item your team tracks as a ticket.
| Action | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| View tickets list | ✓ | ✓ | ✓ | ✓ |
| Search & filter tickets | ✓ | ✓ | ✓ | ✓ |
| Open ticket detail (slide-over) | ✓ | ✓ | ✓ | ✓ |
| Create new ticket | ✓ | ✓ | ✓ | — |
| Change ticket status | ✓ | ✓ | ✓ | Read-only badge |
| Delete ticket | ✓ | ✓ | ✓ | — |
| Select tickets for merge | ✓ | ✓ | ✓ | — |
| Merge tickets | ✓ | ✓ | ✓ | — |
Sidebar navigation
The sidebar itself adapts to the user's role. Configuration-only sections are hidden for Viewers to reduce visual noise and prevent accidental navigation to pages where all actions are blocked anyway.
| Nav item | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Overview | ✓ | ✓ | ✓ | ✓ |
| Emails, Conversations, Forms, Tickets | ✓ | ✓ | ✓ | ✓ |
| Bots (agent config) | ✓ | ✓ | ✓ | — |
| Integrations | ✓ | ✓ | ✓ | — |
| Knowledge Base | ✓ | ✓ | ✓ | — |
| Sage (CRM, Pipelines, Projects) | ✓ | ✓ | ✓ | ✓ |
| Forms (Leads, Sources) | ✓ | ✓ | ✓ | ✓ |
| Analytics | ✓ | ✓ | ✓ | ✓ |
| Settings | ✓ | ✓ | ✓ | ✓ |
Viewers still see Settings so they can check billing info, their own role, and workspace details. All destructive settings (delete workspace, change roles, invite members) are enforced server-side regardless of what the UI shows.
How enforcement works — defence in depth
Permission enforcement in Appalix happens at two independent layers:
1 — UI layer (client-side)
Every page that receives data from the server also receives the caller's role. Client components derive a canWrite boolean (callerRole !== 'viewer') and conditionally render or hide buttons, inputs, and interactive controls. A viewer literally cannot click a “Delete” button because it is never rendered in the DOM.
2 — Server layer (server actions)
Every mutating server action (create contact, delete pipeline, update ticket status, etc.) re-fetches the caller's membership record from the database before executing. Even if someone bypassed the UI and called an action directly, the server would check their role and reject the request. The two layers work independently — neither relies on the other being correct.
Changing permissions via role change
Permissions in Appalix are purely role-based — there are no custom per-user overrides. If you need to give someone additional access, promote their role. If you need to restrict someone, demote them. Role changes in Settings take effect immediately and are enforced on the next page load (the role is read fresh on every server request).
Only the Owner can change roles. See theTeam Seats & Roles guidefor full instructions.
🔐
Set up your team permissions
Head to Settings → Team members to review each member's role and make sure the right people have the right access.