The mechanism
“Why can this user see this record?” — drawn end to end.
Every read walks the same decision path — and the verdict can be explained at each step.
Profile · role
Permissions
The profile sets entity and field permissions; the role hierarchy lets managers see their line.
Team · unit
Shared work · branch scope
Teams share work, and the business unit scopes records to the branch.
Policy · sharing
Per-entity default
The access policy sets the default for each entity; sharing adds the explicit exceptions.
Verdict
READ · via team share
Warranty claim WC‑2210 is readable because it is shared with the user's team.
Field security
Customer phone · masked
Apex Mart, 8,400 and Under review stay visible — the phone shows only its last digits.
Every read walks the same decision path — profile, role, team, business unit, policy and sharing, then a verdict you can explain at each step, down to the masked field.
Security architecture.
Grant
Profiles set entity & field permissions for each user
Scope
Roles, teams & business units narrow what each user sees
Share
Sharing adds explicit exceptions on top of the default
Explain
Any verdict traces back through every step of the path
Audit
A full audit trail keeps every change on record for review
What users can do. What users can see. Separated.
Profiles and field-level permissions govern actions. Record-access policies and ownership govern visibility. Two independent layers — so a permissions change never silently exposes data, and Sense inherits both.
Your org chart, not a permissions puzzle.
Role hierarchies, teams, business units, and record sharing that mirror how the company actually runs — including external audiences like partner reps and distributors, kept firmly outside internal data.
"Why can this user see this record?" Answered.
A full audit trail on every object, a recycle bin with retention, and access diagnostics that trace the exact rule granting visibility — ownership, hierarchy, or share.
Run like infrastructure, not a shared spreadsheet.
For the architects doing the review.
The details an RFP answer needs — all verifiable in a demo.
The questions your architects will ask.
Your data lives in your own tenant, and isolation is enforced at the data layer — every query the platform runs is scoped to the tenant it serves, so multi-tenant efficiency never becomes multi-tenant exposure. Sandbox and production are separate worlds, so test data never reaches the real books. Production runs in cloud data-centre regions in India, with encrypted backups replicated to a second Indian region; the mechanics are on the Trust Center and the hosting commitments in the Data Processing Addendum.
No. Sense runs as the signed-in user, through the platform's own data services, so record-access policies, field-level permissions, team and role boundaries and tenant isolation apply to it exactly as they apply to that person in the application. There is no privileged AI service account and no side door. When Sense proposes an action it drafts the change and waits for the user's approval, and the tool calls, approval decisions and resulting changes are logged with user and conversation context. How Sense Assist works · Responsible AI.
Configuration changes start in a sandbox clone and ship as reviewed, versioned change sets — promoted to production with undo and drift detection, so a release is auditable, repeatable and reversible. The same discipline governs the admin copilot: Sense Control authors changes inactive and activates them only on your approval. Sandboxes and promotion.
Every object carries a full audit trail — data and configuration — recording who changed what and when. A recycle bin with retention keeps deleted records restorable and auditable, and access diagnostics answer "why can this user see this record?" by tracing the exact rule that grants visibility: ownership, hierarchy or an explicit share. AI activity is on the same trail — tool invocations, approval decisions (grants and refusals) and the changes that followed. Record security.
Partner reps, distributors and customers are a separate audience with their own default access — never incidental insiders. They reach the records you choose through customer, commerce and employee portals on your domain, governed by the same security engine: profiles decide what they can do and see down to the field, record sharing extends access explicitly, visibly and revocably, and nothing they do escapes the audit trail. Roles, teams and business units.
Everything in Security & Governance.
Profiles & field-level permissions
Down to the single field.
What a role can do and see, declared to the field level — and enforced on every channel.
Role hierarchies
Managers see their line.
Visibility flows down the reporting chain automatically — no per-user grants to maintain.
Teams & business units
Structure that matches the org.
Shared work through teams; hard scope through business units.
Record access policies
Defaults you set per entity.
Private, team, or unit-wide — each entity gets the default the data deserves.
Record sharing
Exceptions, on the record.
Share a specific record across the line — explicitly, visibly, revocably.
Access diagnostics ("explain why")
The verdict, traced.
See the exact rule granting a user access — ownership, hierarchy, policy or share.
Audit trail
Every change, attributed.
Who changed what, when, from where — on data and on configuration alike.
Recycle bin & retention
Deleted isn’t destroyed.
Deleted records are held with retention — restorable, and auditable.
External-audience scoping
Outsiders stay outside.
Portal and partner users live in a separate audience with separate defaults.
License & capability metering
Entitlements you can read.
Product → feature → capability licensing, with usage metering per tenant.