Underneath
Permission systems are judged on what they do when nothing is configured.
Most of them throw an error, which somebody fixes by granting more than they meant to. A few of them return everything, which nobody notices until an export.
There is a third option and it is the only defensible one.
The question
Asked on every query, and answered the safe way when unanswerable.
Can they read all of this kind of record? Has the workspace deliberately opened this type up? Do they own it? Is it their team's? Has it been shared with them specifically?
And when none of those is true — an empty list. Not an error that somebody resolves by over-granting, and not everything.
- Can they read everything of this kind?→ yes — all of it
- Has the workspace opened this record type up?→ yes — all of it
- Do they own it?→ yes
- Is it their team's, or a teammate's?→ yes, with the team scope
- Has it been shared with them, or with their team?→ yes
- None of the above→ an empty list — never an error, never everything
- Openness is a decision per record type —
Accounts visible to everyone while deals stay private is a normal configuration, and it is one setting rather than a pattern of grants.
- Sharing a single record is first-class —
To a person or a team, read or read-and-write, optionally with an expiry. This is what deal collaborators use, which is why that feature needed no new access path.
- A record you cannot see returns not-found —
Rather than a refusal — because a refusal confirms it exists.
- Roles can be granted for a period —
Cover for somebody's leave that expires on its own rather than being remembered.
- Bulk actions re-check every row —
So a bulk action can never quietly launder a permission you do not hold on an individual record — and it tells you which rows it skipped.
The trail
The audit log cannot be edited. By anyone, including us.
It is not a convention or a policy — the database itself rejects any attempt to change or delete a row, and the application has no permission to try. The retention sweep cannot remove one either.
Every entry carries who acted, from where, with what browser, and what changed. And when somebody from our side is acting inside your workspace with your approval, the entry names both the user they are acting as and the staff member behind it — in your audit log, not only in ours.
- Support access is a two-key process —
A written justification, approval by colleagues who are not the requester, a short window, and revocation available to any administrator as a kill switch. Every step of it recorded in your workspace's own trail.
- An evidence bundle is one action —
A period, and a package of governance reports with a manifest. A report that fails is recorded as having failed rather than failing the bundle.
›Can a manager see their reports' deals automatically?
Through team membership rather than through the reporting line. Put managers in the teams whose records they should see — the org chart alone does not grant visibility.
›Can we create our own permission bundle?
Custom roles are composed from the bundles that ship. Authoring an entirely new bundle is not available today.
›Do territories grant access?
No. A territory classifies; it does not widen what anybody can see. That distinction is on the territories page too, because it is the most commonly assumed otherwise.
›Are reads recorded?
Changes are recorded thoroughly. Reads generally are not — with named exceptions where sensitive values are revealed. Worth knowing if your obligations include access logging.