Security and permissions¶
How the platform keeps firms isolated and gives you fine-grained, predictable control over who inside a firm can see and do what — down to individual fields.
Access control is a product capability you configure, not a fixed set of roles. The result is access decisions that are consistent and testable: the same rules produce the same answers everywhere a user works. The operator tasks behind this page live in the Workspaces & permissions and Users & security chapters of the Operator Guide.
Firms are fully isolated¶
Each firm is a sealed tenant. One firm never sees another firm's accounts, users, brands, or money. Everything below happens inside a single firm — the isolation between firms is absolute and is not something an operator can weaken by configuration.
Roles and permission groups¶
Inside a firm, access is granted through configurable permission groups and roles, not hardcoded job titles. A role names a set of capabilities — such as agent, manager, or administrator — and a permission group bundles roles with the resource access they apply to. How far a user reaches derives from their home business unit together with those grants. You assign permission groups to users to keep access consistent across your team, and you can adjust them as your firm grows without touching code.
The hierarchical glass wall¶
A firm organizes its team into business units — a tree of desks, regions, or departments. This tree acts as a "glass wall": a user can see and act on accounts according to the reach their position grants, and no further. Reach is scoped by level — for example, only a user's own accounts, their business unit's accounts, their unit and everything beneath it, or the whole firm — so a manager sees exactly what their place in the hierarchy permits, no more and no less.
Clear account ownership¶
Every account has exactly one owner: a user, a business unit, or the firm. Ownership decides who can reach an account. An account owned by a business unit acts as a shared pool that eligible team members can claim, which — combined with lead assignment — lets you route work fairly and keep accountability clear.
See Who can reach an account and Configure lead assignment.
Field-level security¶
Control extends below the record. With field-level security, sensitive or personal fields — a government ID, say — can be masked for users who should not see them, even when those users can otherwise open the record. When a permitted user needs a protected value, it is revealed through a controlled, audited step.
Auditability and safe impersonation¶
Every change is attributable: the platform records who made a write and where it came from, so you can review the history behind any record. See View a record's change history.
Administrators can also step into a user's view to troubleshoot — "viewing as another user" — with a banner making the impersonation visible and an audit trail that records both the administrator and the user acted as, so a stand-in session is never anonymous.
Note
When an administrator is viewing as another user, a banner stays on screen for the whole session. See The "viewing as another user" banner.