Goal
Create a custom permission group and correctly scope cross-office and feature access so agents inherit the right capabilities without overexposure.
When You Need a Custom Group
- A role sits between standard Agents and full Administrators.
- You are delegating operational oversight (reports or select modules) without granting security configuration rights.
- You want a staging group to pilot new feature permissions safely.
Pre‑Requisites
- Clarity on which modules the group must access (list them beforehand).
- Decision on whether the group requires cross‑office visibility (see Office Isolation article).
- At least one test user you can assign to validate behavior.
Tip: If your goal is to remove peer record visibility from the default AGENTS role, start by cloning it as the base group and then set Agency: Access to data related to any agent to No. Combine with cross‑office restriction if you also need office isolation.
Steps to Create the Group
- Navigate to
Administration > Security > Permission Groups. - Click New Group and provide a clear name (e.g. Senior CSR).
- Select a Base Group if you want to inherit an existing baseline (e.g. Agents). This pre‑loads default rights.
Selecting a base group accelerates setup; you can still override individual rights below. - Use the permissions search to filter and adjust only what differs from the base.
- If the group must remain isolated to an agent's own office, ensure the cross‑office access right stays No. Otherwise set it to Yes.
Leave this right at No unless the role legitimately needs to see all offices. - Review higher‑risk rights (security admin, bulk operations, destructive actions) and confirm they’re intentionally granted.
- Save the group.
- Assign the test user to the new group and log in (or impersonate) to validate expected access.
Validation Checklist
- Correct modules visible; unneeded modules hidden.
- Office scoping behaves as intended (try searching for another office’s customer).
- Reports tab: only expected reports accessible.
- No unintended security configuration rights exposed.
Best Practices
- Name groups by function + level (e.g. Accounting Read, Sales Lead Full).
- Document rationale for any elevated permission in an internal changelog.
- Review custom groups quarterly for drift (permissions accretion).
Rollback / Removal
- Reassign users back to their prior group (e.g. Agents).
- Archive or delete the custom group after confirming no active members.