Goal
Restrict an agent so they only see records (customers, policies, tasks, activities) directly assigned to them, instead of all records owned by other agents in the same office.
When You Should Enable It
- Roles where agents should not browse or prospect other teammates' books of business.
- Minimizing accidental edits or data leakage inside a single office.
- Pairing with office isolation for a strict least‑privilege posture (agent sees only: their own + their office if explicitly needed).
- Training / probationary users who should operate in a narrow, auditable scope.
Pre‑Requisites
- Agent user accounts are correctly linked to their records (creator/owner assignments accurate).
- Permission groups strategy defined (e.g. Agents (Standard) vs Agents (Restricted)).
- If combining with office isolation, confirm that Agency: Access to data all across the offices is already set appropriately (usually No for restricted roles).
Default system role behavior: The built‑in AGENTS system permission group (if you are using it directly) typically leaves agent-to-agent visibility enabled. To restrict agents to only their own records you must create a custom permission group cloned from AGENTS (or from a suitable base), then explicitly set Agency: Access to data related to any agent to No (and optionally disable cross‑office access).
Key Access Right (Agent Data Scope)
The restriction is enforced by disabling the access right that allows viewing data related to any agent. Setting it to No filters lists, searches, and dashboards to the signed‑in agent's own assignments (unless they are the explicit owner or participant).
Important interplay: This right operates inside an office. To prevent cross‑office viewing you must also evaluate “Agency: Access to data all across the offices”. For the most restrictive model: set BOTH rights to No. See: Office Data Isolation and overall context in Platform Security Overview.
Steps to Restrict Agent Visibility
- Navigate to
Administration > Security > Permission Groups(or open an individual user’s Permissions panel). - Create or select the permission group intended for restricted-scope agents.
- Use the search box and type a portion:
related to any agent. - Set Agency: Access to data related to any agent to No.
- (Optional cross‑office pairing) Also set Agency: Access to data all across the offices to No if you want: Only their own + same‑office isolation.
- Save / apply the permission group changes.
- Impersonate or log in as a test restricted agent and verify filtered views (see validation below).
Validation Checklist
- Customer / Policy list only shows records where the agent is the assigned/primary agent.
- Global search returns fewer results than a peer with broader visibility.
- Opening a teammate’s customer record via direct URL is blocked or redirected (depending on platform enforcement layer).
- Dashboards / widgets reflect only that agent’s production metrics.
Immediate Effects
- List queries constrained to self‑owned records.
- Opportunity / pipeline style metrics limited to personal book.
- Reduces accidental data modification of peer accounts.
- Simplifies UI (fewer irrelevant records).
Audit & Monitoring
Quarterly, impersonate a restricted agent and confirm no access to peer records. Review support tickets for agents requesting access they should not have—this can reveal misapplied permission groups.
Rollback Procedure
- Open the affected permission group (or user permissions).
- Set Agency: Access to data related to any agent to Yes.
- (If previously changed) Adjust cross‑office right as needed.
- Save. Agent now sees all office records (and possibly cross‑office if that right is also Yes).