Connect one org
A customer admin authorizes a Salesforce org.
Admins publish a bounded assistant surface. Users get named access to one assistant at a time. If that sounds narrower than most AI tools, that is the point.
This page is intentionally plain. We would rather be specific than sound impressive.
Bounded surface. Named-user runtime. Brutal honesty about what exists today.
A customer admin authorizes a Salesforce org.
The assistant gets a defined data surface and tool set.
Assistant access is granted deliberately, not implied.
Each session resolves to tenant, org, user, and assistant.
If a question falls outside the published assistant surface, there is no general-purpose path around that surface. Preview, release review, session binding, and audit logging are part of the product model, not extras layered on later.
The admin chooses what an assistant can read object by object and field by field.
Users receive assistant access explicitly instead of inheriting broad workspace access.
Runtime context is tied to one tenant, one org, one user, and one assistant.
Assistant invocations record runtime metadata with tool, timing, status, and outcome.
| Capability | Status | Current posture |
|---|---|---|
| Invocation log per user | Partial | Runtime events exist. The polished customer-facing console does not yet. |
| Record / field provenance | Partial | Tool and action shape are captured today. Full customer-facing provenance is not. |
| Compliance export | Not yet | Planned for GA rather than rushed into early access. |
europe-west1 today.We would rather answer a direct security or architecture question than hide behind a demo flow. If the current posture is too early for your process, say so. That is useful information.
Tell us what part of the review you are in: architecture, procurement, questionnaire, or data processing.