Roles and permissions

A role is the simplest way to control access: assign someone admin, manager, member, or viewer and KudosCRM applies the right reach across the CRM. Behind the role sits a layered permission engine that's enforced everywhere, so access is consistent whether someone's in deals, contacts, tasks, or settings.

This guide sets a user's role in the admin console and explains how enforcement works — including the deny-wins layering and per-user overrides that let you tune one person's access without changing everyone's. The visual matrix editor for hand-building a role is on the roadmap; today you assign roles and rely on the engine to enforce them.

Who this is for

Workspace admins who manage who can do what, and managers who need to understand what their team can see and change.

Before you start

• A KudosCRM account with admin access to the user console.
• The teammates you want to set roles for already invited or active in the workspace.
• A clear idea of the four roles — admin, manager, member, viewer — and what each should reach.

Permissions are deny-wins and audited
KudosCRM resolves access in layers — role defaults, then per-role and per-user overrides — and a deny always wins over an allow, so a tightened permission can't be loosened by accident. Every override is recorded in the audit trail, so you can always see who changed access and when.

Set a user's role, step by step

1. Open the user console
   Go to your team settings and open the user console. Search or filter to find the teammate you want — for example, Maria Chen on the sales team.
2. Choose the right base role
   Edit the user and set their role. Admin manages the whole workspace; manager oversees a team; member does day-to-day work; viewer sees but can't change. There's also a sales-role overlay for sales-specific reach on top of the base role.
3. Understand how enforcement applies
   Once you save, the permission engine enforces the role across the CRM — deals, contacts, tasks, settings, everywhere. You don't wire each screen by hand; the role drives what each person sees and can do consistently.
4. Apply a per-user override when needed
   If one person needs slightly more or less than their role, apply a per-user override. Remember deny-wins: a denial sticks even if another layer would allow it, so use overrides to tighten precisely without rebuilding a role.
5. Adjust access as people change roles
   When someone moves teams or takes on more, change their role in the console and the engine re-applies their access immediately. Pair this with deactivate-with-successor when someone leaves so their open work reassigns cleanly.
6. Review changes in the audit trail
   Open the audit log to confirm a role or override change landed and to see who made it. Every access change is recorded, so you keep a clean history for security reviews.

What you get

• Four clear roles — admin, manager, member, viewer — plus a sales overlay, set in one console.
• Consistent enforcement across the whole CRM from a layered, deny-wins permission engine.
• Per-user overrides to tune one person's access without changing everyone's role.
• An audit trail of every access change, so security reviews are quick and clean.

Frequently asked questions

What are the four roles, and what can each do?

Admin manages the whole workspace including settings and users; manager oversees a team and its work; member does day-to-day CRM work; viewer can see records but not change them. A sales-role overlay adds sales-specific reach on top of the base role for people who live in the pipeline.

Can I build a custom role from a permission matrix?

Assigning and changing roles is live in the admin console today, and the deny-wins engine enforces them across the CRM with per-user overrides. A visual, editable permission-matrix screen for hand-building a role from scratch is on the roadmap — so for now you work from the four roles plus overrides rather than designing a role grid.

How does deny-wins actually work?

Access resolves in layers — role defaults first, then per-role and per-user overrides. When two layers disagree, a deny beats an allow. That means once you tighten a permission, another layer can't quietly re-open it, which keeps sensitive access predictable.

Are permission changes recorded?

Yes. Every per-role and per-user override is written to the audit trail, so you can always see who changed access, what changed, and when. That history makes security reviews and access audits straightforward.

Learn more

• Security & roles (feature) — Everything KudosCRM access control does, on the feature page.