Security Roles Explained

This closes a question deferred from the CRM documentation: "How do I control which users can see which leads (RBAC/territory)?" There's no territory concept anywhere in the product — visibility is entirely rights-based, resolved the way this article describes. CRM-specific rights like View Leads and View Unassigned Leads are just two leaves in the same rights tree covered here.

A Security Role is a named bundle of permissions ("rights") a member can be assigned. Three system roles are seeded by default — Members, Team Members, and Administrator (Full Access) — alongside any custom roles your organization creates. System roles can be locked against renaming or deletion; when both are locked, the role shows Protected instead of an Edit button.

Rights aren't a flat checklist — they're a tree

Individual rights have parent/child relationships. For example, View Leads is the parent of Create Leads, Edit Leads, Delete Leads, Assign Leads, View Unassigned Leads, and View Lead Contact Info Others (which itself parents Edit Lead Contact Info Others). Granting a right automatically grants every ancestor above it. Explicitly denying a right automatically denies every descendant currently granted below it. Some rights — like Manage CRM Settings — stand alone with no parent or children.

Each right is three-way, not on/off

Every right on a role can be set to:

• Granted — the role has this permission.
• Not Specified — falls back to whatever the level below resolves to (see the waterfall, next).
• Nuke — explicitly denied, overriding anything a lower level would otherwise grant.

The waterfall: where an effective permission actually comes from

A member's real, effective rights aren't just "their role's rights." They're resolved through several layers, most specific wins:

Security Model (organization-wide baseline, set on Branch Types) → Role(s) (a member can hold more than one) → Department → Job Title → Member-level override.

A more specific level can override a less specific one — a Department-level Nuke can be overridden by that member's Job Title granting it back, for instance. Departments, Job Titles, and individual members can all carry their own direct rights on top of whatever their roles grant, using the exact same Granted/Not Specified/Nuke tree.

Honesty labels worth knowing

• "Not yet enforced" — a right exists and can be toggled, but doesn't currently gate anything in the platform yet. There are a baker's dozen of these today (mostly around scheduling, time off, and meeting recording) — toggling them has no effect until the corresponding feature enforces them.
• "Enforced elsewhere" — this right has been superseded by a different right name.
• A struck-through "Inert" state can appear on old data written before the hierarchy existed, where a right is Granted but its ancestor isn't — the editor itself can't produce this, only inherit it.