Skip to main content

Permissions and Roles

Every button, page, and action in the CRM is gated by a permission. If something is visible to one employee and not another, it's because their permissions differ — not because they have a different "role" in any fixed, named sense. Understanding how permissions work explains why the platform looks and behaves differently depending on who's logged in.

Permissions are attached to employees​

The fundamental unit is the permission, and permissions are attached to employees — either directly as individual grants, or through a Permission Group (a named set of permissions that can be applied to multiple employees at once).

When an employee logs in, the system loads their permission set and uses it to decide which navigation items, pages, buttons, and actions are visible. A page the employee doesn't have permission to access simply doesn't appear. A button for an action they're not permitted to take is hidden or disabled.

This means two people with the title "Sales Agent" can have different capabilities depending on which permissions their accounts carry. Title and permissions are independent.

User types​

At the broadest level, there are two distinct user populations:

  • Admin / Employee users — the internal team using the CRM admin panel. This includes agents, managers, finance staff, compliance officers, and admins. Their access is entirely driven by permissions.
  • Customers — the external clients using the customer portal. Their experience is governed by a separate set of rules and is not configurable via the HR permissions system.

Within the employee population, there's no hard "manager role" built into the system. An employee has manager-level capabilities because they've been granted the permissions that cover manager tasks — approving Data Change Requests, accessing approval queues, configuring lead stages, reviewing calls. Strip those permissions, and the "manager" loses those capabilities. Add them to an agent, and the agent gains them.

Permission groups make administration practical​

Managing permissions one employee at a time would be tedious in a team of any size. Permission groups solve this. An admin creates a named group — "Sales Agent", "Team Manager", "Finance Officer", "Compliance" — assigns the relevant permissions to it, then assigns the group to each new employee in that role.

When the group changes (e.g., a new feature is rolled out and all agents need a new permission), updating the group updates every employee in it at once.

An employee can be assigned a group and also hold individual permissions that the group doesn't cover. The effective permission set is the union.

What permissions control in practice​

  • Navigation — Which sidebar sections and sub-menus are visible
  • Lead actions — Whether the employee can assign leads, create transactions, apply tags, change stages
  • Approval queues — Whether the employee can see and action Data Change Requests or Lead Transactions
  • Settings and configuration — Whether they can create lead stages, tags, pools, targets, and commission plans
  • Reports and insights — Whether they can view other employees' performance data, call recordings, or commission reports
  • HR — Whether they can manage employees, teams, leave, and payroll

See also​