Who sees which deals: visibility scopes

Every record permission (view / edit) carries a scope — whose records it covers. The scope is set per permission in the role editor at Settings → Roles & access, so the same role can, for example, view all deals but edit only its own.

The five scopes

Scope	Who is covered
Own	Only records where the person is the owner
Team	Records of every member of the person's team
Subtree	Everyone in the person's org subtree — their team leads and those leads' teams
All	Every record in the workspace
Projects	Only records linked to a post-sale project (its deals and participants)

Scopes are enforced in the data layer, not just hidden in the UI: every list query filters rows by the viewer's scope, and every edit re-checks the scope against the specific record. Record detail pages work differently: opening a record by direct link or from search is a point lookup, readable by any workspace member whose role has the view permission at all. A manager scoped to Own can open a colleague's deal that way — read-only: it never appears in their lists, and editing is still rejected by the scope check.

Records without an owner (for example, fresh unassigned leads) pass that record-level check for anyone who holds the permission — but they do not appear in lists scoped to Own, Team, or Subtree, because those filters match by owner and an ownerless record matches nobody. Assign an owner (or use an All-scoped role) to surface them in lists.

Defaults per built-in role

• Manager — Own on deals, contacts, companies, and tasks. A new manager does not get the whole customer database on day one: their lists and boards show only their own records. Searching by an exact email or phone still surfaces an existing contact outside the scope (read-only, per the rule above) — that is how duplicates are avoided.
• Team Lead — Team on deals, contacts, companies, tasks, and inbox. The board still defaults to their own deals; teammates' cards are pulled in via the owner filter, which itself only offers people from the team.
• Head of Sales — Subtree: their team leads plus those leads' teams, following the reporting lines you set on the Team page. Not the whole workspace.
• Sales Director, Admin, Owner — All.
• Customer Support — Projects: only deals handed off to a post-sale project and the contacts participating in it.

Admins can change any of these in the role editor — for example widen Manager's contact visibility to Team.

What feeds Team and Subtree

Both scopes are driven by the structure on the Team page: teams with their leads (board view) and the "reports to" lines (org chart view). Move a person to another team and their lead's visibility follows automatically.

Personal views are hard-scoped

Pages that present "my" data — the personal Insights view, "my" dashboards and queues — are always computed for the signed-in user only. Owner and manager filter pickers across reports show only the people your scope lets you see, so you cannot even ask for a colleague's rows if your role does not cover them.

Scopes are one half of access control; the other half is the action grants themselves — see Roles and permissions.