Preparing Data Access for Salesforce AI
Salesforce AI needs an access model that is specific to the task it will perform. An assistant answering an employee’s question and an external-facing agent taking an action can involve different identities, data, and execution contexts. A general statement that the platform respects permissions does not resolve those differences.
Before expanding a workflow, identify who or what acts, which records are available, what operation is permitted, and where human approval is required. Then test both the intended action and a relevant action that should be denied.
Official training material offers useful examples, but an example is not a universal rule for every agent channel or Flow configuration. The practical goal is a reviewable action-access matrix for the actual scenario, supported by evidence from the proposed environment and commercial model.
Key Takeaways
- Resolve the runtime identity. Do not infer it from the person who created the agent or from an unrelated example.
- Limit the action. A read-only lookup and a record-changing workflow require different acceptance conditions.
- Test restricted cases. A successful permitted request does not demonstrate that other information or actions are inaccessible.
- Keep pricing models separate. Credits and conversations are distinct commercial units and need their own assumptions.
Start With One Defined Agent Scenario
Choose a bounded business task before discussing broad agent access. Describe the user, the required result, the source records, and the operation that produces the result. Identify the consequence of an incorrect answer or unintended change.
For an employee lookup, the intended operation may be read-only and limited to information the employee is permitted to use. For an external-facing scenario, the workflow may need a more constrained identity and a narrowly defined action. Those are illustrative cases, not configuration instructions.
Broader AI investment and production use findings can explain why organizations are evaluating these systems. They do not establish that a particular workflow is ready. The production decision needs evidence about its own access and action boundaries.
Write the acceptance condition in operational terms. The system should complete the intended task, return only appropriate information, and route unsupported or disallowed requests to the defined failure path. A demonstration that produces a plausible answer is not sufficient when access or action restrictions are material.
Salesforce AI becomes easier to evaluate when the task is narrow enough that the team can describe the expected result and the conditions under which it should refuse or escalate.
Verify the Execution Context
Salesforce’s Trailhead material on agent flow access distinguishes an employee-facing user context from a dedicated user for external-facing agents in the training scenario. It also emphasizes controlled data return. That example should not be generalized into a rule for every Flow or agent deployment.
For the actual workflow, establish the identity and context under which each relevant action executes. Identify the permissions and data access associated with that identity. Confirm how the scenario differs from the training example before relying on its assumptions.
Separate the person initiating a request from the identity that performs the downstream operation. They may be related, but the relationship must be established for the selected channel and action. The account used to build or connect a workflow is another distinct role that should not be confused with the requester.
Record the source of the conclusion. Use the applicable product documentation, configuration review, and observed test behavior. If the execution context remains unclear, that is an unresolved production requirement, not a minor documentation gap.
The access model should be understandable to the data owner as well as the builder. The data owner needs to know which identity can obtain or change which information and why that access is necessary for the business task.
Build an Action-Access Matrix
The matrix below describes two illustrative scenarios. It is intended to structure assessment, not to prescribe production permissions or claim that a particular tenant already behaves this way.
Diagram
Build an Action-Access Matrix
- Task
- Runtime identity
- Source objects
- Allowed operation
- Approval
- Negative test
- Audit evidence
| Review Field | Employee Lookup Example | Restricted External-Agent Example |
|---|---|---|
| Task | Retrieve approved information for an employee | Complete a narrowly defined external request |
| Runtime identity | Verify the applicable employee-facing context | Verify the dedicated or other applicable execution identity |
| Source objects | Only those required for the lookup | Only those required for the specific external task |
| Allowed operation | Read-only retrieval | Explicitly bounded operation |
| Approval | Defined by the information and process | Required where the organization’s process calls for it |
| Negative test | Restricted record or field is not returned | Out-of-scope request does not gain broader access or action |
| Audit evidence | Request, identity, relevant action, and result | Same evidence, including any approval or escalation |
Expand the matrix only when the workflow genuinely requires more scope. Each additional source or action creates another access question and another test condition. A broad initial permission set can make a demonstration easier while obscuring the actual requirement.
For every row, identify an owner who can approve the intended behavior and review the evidence. The builder should not be left to infer business authorization from the technical ability to grant access.
Salesforce AI readiness can then be reviewed action by action. That is more reliable than assigning a single “secure” status to an agent whose different operations have not been examined.
Control What the Action Returns
Permission to read information is only part of the assessment. Review what the action returns to the agent and what the agent presents to the requester. The returned data should be appropriate for the defined task and audience.
Avoid returning a broad record collection simply because the downstream component can later select from it. The assessment should ask what information is necessary to complete the task and how unnecessary fields or records are excluded.
Test representative edge cases. A request involving a restricted record, an ambiguous identity, incomplete information, or an unsupported operation should follow a defined route. The system should not compensate for uncertainty by expanding its access or inventing a result.
The same concern appears in Atlassian knowledge permissions: the source, effective identity, and execution context determine what information can be returned. Similar principles apply across products, but the actual behavior must be verified for each system and connector.
Keep the evidence of the returned content, not only the fact that the action ran. A successful technical execution can still produce an inappropriate or incomplete result for the business process. Acceptance should cover both access behavior and task quality.
Separate Approval From Technical Permission
A system may have the technical ability to perform an operation while the business process still requires human approval. Those are different controls. The action matrix should identify both the permitted operation and the approval condition.
For a consequential change, define who can approve it, what information the approver receives, and how the outcome is recorded. Test what happens when approval is absent, rejected, delayed, or no longer valid for the requested action.
Avoid treating a user’s general access as permission for every automated action on their behalf. The workflow should reflect the organization’s actual decision rules. The fact that a person could manually make a change does not automatically settle how an agent should make it.
Include a failure route that preserves the business process. An agent should be able to escalate or decline an unsupported request without leaving the work in an unowned state. The receiving team needs enough context to continue safely.
This makes the workflow operationally usable. Users know when the system can act, when a person must decide, and how exceptions are handled. It also creates evidence that can be reviewed after the action.
Model Consumption Using the Applicable Unit
Salesforce’s Agentforce pricing units include distinct models such as $500 per 100,000 Flex Credits and $2 per conversation. Those listed units should not be converted into one another without the applicable action and consumption model.
A conversation and a credit are not interchangeable measures of work. The number and type of actions within a scenario can affect consumption, and the relevant commercial arrangement must be confirmed for the proposed use.
Build the estimate from the bounded workflow. Record the expected task volume, the relevant meter, the applicable rate or allowance, and the source of each assumption. Keep measured pilot usage separate from an untested production forecast.
The comparison with Snowflake AI compute costs is useful at the level of method: preserve native meters and pricing classes rather than applying one universal conversion. The specific Salesforce commercial model still needs its own documentation and quote.
Measure cost per accepted outcome where that helps the decision. Include retries, rejected outputs, and review effort when they are part of completing the task. A low cost per action does not necessarily imply a low cost per successfully completed business process.
Pilot With Allowed and Denied Cases
A pilot should demonstrate the intended access boundary as well as useful output. Create a small set of representative cases with expected results agreed by the business and data owners.
Include an ordinary permitted request, a restricted-information request, an unsupported action, and a case requiring human review where relevant. Test the observed behavior rather than relying only on configuration labels. Retain enough evidence to explain why the result passed or failed.
Measure task quality and access behavior separately. A response can be accurate but inappropriate for the requester, or properly restricted but unhelpful for the permitted task. The production decision needs both dimensions.
Review changes made during the pilot. If a builder broadens permissions to resolve a failed case, repeat the restricted tests. A fix that improves task completion may alter the access boundary, so the earlier test result may no longer be sufficient.
Salesforce AI should expand only after the next scope of use has a defined acceptance basis. Success with one task and identity context does not establish readiness for every channel, data source, or action.
Maintain the Access Model After Launch
The action matrix should remain an operational record. Update it when the workflow, source data, role model, connector, or commercial arrangement changes. Identify which changes require retesting before wider use.
Assign ownership for usage and exception review. The team should be able to explain unusual consumption, repeated failures, and requests that frequently require escalation. Those patterns can reveal a mismatch between the intended task and the way people are using the system.
Keep the rollback route practical. If the workflow behaves outside its approved scope, the organization needs a defined way to pause or restrict it while the issue is investigated. The business process should have an owner who can manage the resulting work.
The goal is a production system whose behavior remains explainable as it evolves. A clear identity, a bounded action, appropriate returned data, and retained test evidence provide a stronger foundation than a broad claim that the agent is ready because the demonstration worked.
A useful negative test should be meaningful to the data owner. Choose a controlled record or field that the requester should not receive and define the expected refusal or limited response. Inspect the returned content as well as the action status. If the test passes only because the sample data happens to omit sensitive information, it has not established the intended boundary. Preserve the scenario so later permission changes can be checked against the same expectation.
Frequently Asked Questions
Do All Agent Flows Run in the Same Context?
The cited training scenario does not establish a universal execution rule. Verify the runtime identity and context for the actual agent channel and action. Use the applicable documentation, configuration review, and observed tests rather than assuming every scenario behaves alike.
Is Read Access Enough to Approve a Workflow?
No. Review the information returned, the audience, the permitted operation, required approvals, and failure handling. The task should return appropriate content and complete the intended process without expanding access beyond its approved scope.
Can Flex Credits Be Converted Directly Into Conversations?
Not without the applicable consumption model. They are distinct pricing units. Build the estimate from the actual workflow and commercial arrangement, preserving the meter, rate, volume assumptions, and observed pilot usage.
What Makes a Pilot Ready to Expand?
An agent pilot is ready when it demonstrates useful outcomes and the intended access boundary, including relevant denied and approval cases. The next scope should have its own owner, cost assumptions, acceptance conditions, and retest triggers.
Resources
Salesforce’s agent-ready Flow training supplies the scoped execution-context example. Agentforce pricing supplies the listed commercial units. Both are linked above. The action matrix and testing framework are editorial operating recommendations, not tenant-specific permissions or deployment instructions.