TBW / SALESFORCE / USE CASE
Salesforce Workflow Automation
Use AI for CRM enrichment, triage and recommendations while respecting Salesforce authorization and approval boundaries.
The Problem: CRM Context Without Permission Drift
Lead records arrive incomplete, account context is gathered by hand, and sales teams correct routing after the fact. An AI assistant can propose the missing context, but connecting it through an overpowered integration identity can expose records a requester should not see. Direct model-initiated writes can change protected fields without an owner approving the exact change.
Separate suggestion from execution. A proposed owner or next step is not authority to update a Lead or Opportunity. Define who may see the source fields, who may approve the proposal, and which fields the connector may write before enabling any API update.
A Suggestion Is Not a Salesforce Update
Record/Event → Read Permitted Fields → AI Suggestion → Policy/Human Review → API Update → Audit. A changed record or approved intake event starts a bounded task. The connector reads only fields the effective identity is permitted to access and that this workflow needs. The model drafts a recommendation with supporting record references and uncertainty, never an executable API request.
A policy check then rejects disallowed destinations, fields and sensitive changes. A named reviewer sees the current record values beside the proposed values and approves or rejects the exact payload. Only the approved, revalidated update reaches Salesforce; record the event ID, identity, source version, review decision and API result. If the source changes before execution, return to review instead of applying an obsolete suggestion.
Identity, App Authorization and Record Access
Client app and OAuth
Register an external client app or connected app as appropriate for the org and API. Choose an OAuth flow and scopes for the actual operation; review app access policies and token handling. An api scope enables API access for the logged-in identity, not blanket access to every record or field.
Running identity
For system-to-system work, consider a dedicated, minimally permissioned integration user per integration rather than a shared administrator account. Keep production and sandbox credentials and app configuration separate. For a user-facing assistant, explicitly preserve each requester’s effective access; a shared integration user can otherwise read across users.
Permission boundary
Check organization policy, object CRUD, field-level security and record sharing for the executing identity, plus the requesting user’s rights in a multi-user flow. The API respects the logged-in user’s effective access, but a highly privileged service identity is not a substitute for requester-level authorization. Custom Apex or middleware must enforce its own relevant access checks.
Action boundary
A connector, not the model, owns tokens and API calls. Use a workflow-level field allowlist and compare approved payload with the outgoing call. Record duplicate-event keys and handle retries without repeating a change; upsert is not automatically safe when creation is unwanted.
OAuth scopes determine which APIs the client can invoke, while Salesforce object, field and sharing permissions constrain the running identity’s effective data access. Design and test both layers, then impose the workflow’s narrower task boundary.
Four CRM Patterns with Different Review Decisions
- Lead Triage: suggest a routing category and owner from allowed Lead fields, then let the queue owner confirm reassignment. Test ambiguous and restricted leads before enabling an owner update.
- Account Research Summary: draft a cited brief from permitted Account context and approved external research; leave the source record unchanged and flag claims that cannot be verified.
- Opportunity Next-Step Draft: propose a follow-up task or note from allowed Opportunity context. A sales owner checks stage, audience and language; do not silently change stage, amount or forecast.
- Data-Quality Proposal: surface a suspected duplicate or missing value with the old and new values for a steward. A suggested correction must not overwrite a protected field or merge records without the established approval path.
Each pattern names a different reader, reviewer and write destination. A single broad integration account should not erase those distinctions.
Controls That Survive Model Errors
- Field-write allowlist: permit only named object/field combinations and operations in the connector; keep sensitive owner, forecast and protected fields behind additional review or out of scope.
- Human approval: show old/new values, source references, reviewer and destination; reject changed payloads or stale record versions before execution.
- Idempotency: deduplicate by event and proposed action in the workflow, preserve decision IDs across retries and inspect the API response. If using external-ID upsert, account for its create-on-no-match behavior or use update-only where appropriate.
- Environment and app review: rehearse with representative access restrictions in a sandbox, isolate tokens from production and periodically review external client/connected app grants, OAuth scopes and user permissions.
- Audit: correlate trigger, executing and requesting identities, permitted fields, proposal, approval/rejection, write payload and Salesforce outcome without placing secrets or unnecessary CRM data in logs.
What the Pilot Produces
- An object-and-field access matrix naming the requester, running identity, readable fields, proposed writable field, reviewer and denial case.
- A client-app/OAuth and dedicated-identity decision record, including sandbox/production separation and credential owner.
- A field-write allowlist and approval contract showing the exact old/new-value payload, stale-record rule and rejection path.
- An event-to-action trace with deduplication key, retry behavior and a reversible update procedure for operators.
- A test sheet covering permitted and denied records, protected fields, scope drift, duplicate events and token revocation.
These are proposed pilot artifacts, not evidence of a deployed Salesforce integration.
Measure Decisions, Not Generated Volume
Baseline the existing manual process, then track accepted and rejected suggestions with reasons, completeness of the selected data fields, routing corrections, pending approvals and manual reversals. Review how often access or policy checks deny a proposal, and whether audit traces explain each applied update. Set targets after the owner sees a baseline; this pattern assumes no customer results or numerical benefit.
Start with One Object and One Approved Field
- Sandbox read and suggest: choose one object, a named reviewer and a small set of permitted fields. Inventory the app, OAuth flow, running identity and effective permissions. Generate suggestions only; test records hidden by sharing and fields denied by field-level security.
- Review before any write: compare proposals with human decisions, reject sensitive or unsupported changes, rehearse stale-record and duplicate-event handling, and verify the trace and stop procedure.
- One approved update: only after the read-only evidence is satisfactory, allow one reviewed field update through the Salesforce API in the sandbox. Check the saved value, authorization failure paths, retries and reversal before considering production scope.
Salesforce Risks and Denial Tests
| Risk | Control and denial test |
|---|---|
| Overpowered integration account | Use a dedicated, least-privileged identity and test records visible to that identity but denied to a requester; do not use its broad access as requester authorization. |
| OAuth scope or app-access creep | Inventory app policies and scopes, review grants after changes and test an API or user outside the approved workflow boundary. |
| Protected field change | Enforce the object/field allowlist and require additional approval for sensitive fields; attempt a disallowed update and verify no write occurs. |
| Shared credentials or exposed tokens | Separate environments and identities; keep tokens outside prompts/logs, revoke a test credential and verify the connector stops. |
| Duplicate or stale updates | Deduplicate event/action IDs, re-check current values before executing and test repeated delivery and a concurrent human edit. |
Frequently Asked Questions
Does an OAuth api scope let the assistant see every Salesforce record?
No. The scope permits API use for the running identity; object and field permissions and record sharing still govern that identity’s access. A multi-user assistant must also enforce the requesting user’s access instead of assuming a service account represents everyone.
Should every workflow use a dedicated integration user?
For a system-to-system connector, a dedicated, minimally permissioned identity per integration is usually preferable to shared credentials. A user-facing workflow may need user-context authorization as well; choose the flow by who should be able to see and approve each record.
Can AI change an Opportunity stage after a recommendation is accepted?
Only if that field and action are deliberately in scope, the appropriate user can authorize it and a reviewer approves the exact current-to-proposed value. The initial pilot leaves stage and forecast changes unavailable.
How do retries avoid duplicate Lead updates?
Track a unique event and action decision in the workflow, compare the current record with the reviewed values and do not repeat an already completed action. An external-ID upsert can create a new record when nothing matches, so it is not a blanket retry safeguard.
What happens when a record changes while approval is pending?
Re-read the permitted fields and compare the current value/version with what was shown at approval. If material data changed, invalidate the proposal and request a new review rather than applying a stale update.
Scope a Salesforce Suggestion-First Pilot
Bring one CRM object, the fields your team currently checks and the person who owns the approval. We can map effective access, a sandbox suggestion flow and a single reviewed write before expanding integration rights.