You are here:
Agent Execution Context and Data Access by Type
Learn how Agentforce Employee, Lead Nurturing (Sales), and Service agents run actions and how data access is controlled for each agent type.
Execution Context by Agent Type
Execution context varies by agent type, channel, and whether credential-based user verification is enabled (available for agents connected to Enhanced Chat v1 and deployed to Experience Cloud sites only).
| Employee Agents | Lead Nurturing Agents | Service Agents | |
|---|---|---|---|
| Primary Use Case | Internal employees | Automated outreach to external leads, prospects, and customers | External customers and partners |
| Supported Channels | Lightning Experience, the Salesforce mobile app, Slack, and Enhanced Web Chat v1 (Experience Cloud sites only) | Outbound email | Enhanced messaging channels, including Enhanced Chat v1 and Enhanced Chat v2 |
| Runs As | Logged-in end user | Agent User (EinsteinSDRAgent User) | Without credential-based user verification: Agent User (EinsteinServiceAgent User) With credential-based user verification: Logged-in site user (Enhanced Chat v1 and Experience Cloud sites only) |
| Data Access Governed By | End user’s profile, permissions, field-level security, and sharing rules | Agent user profile, permissions, field-level security, and sharing rules | Without credential-based user verification: Agent user profile, permissions, field-level security, and sharing rules With credential-based user verification: Logged-in site user’s profile, permissions, field-level security, and sharing rules (Enhanced Chat v1 and Experience Cloud sites only) |
| User Identified By | Logged-in end user | Lead or contact context | Without credential-based user verification: Context variables
(for example, With credential-based user verification: Logged-in site user (Enhanced Chat v1 and Experience Cloud sites only) |
Flow Run Context and Agent Execution
Flows run in user context or system context. When an agent action runs a flow, both the flow’s run context and the agent’s execution context apply. Learn more about flow run context.
| Flow Run Context | Common Use | Object and Field Access | Sharing Rules |
|---|---|---|---|
| User | Standard interactive flows | Governed by running user’s permissions and field-level access | Running user’s sharing rules |
| System context with sharing | Elevated access that respects data visibility | All objects and fields | Running user’s sharing rules |
| System context without sharing | Background automation that requires full access | All objects and fields | N/A |
Employee Agent Execution Context Details
Agentforce Employee agents are intended for internal users accessing the system via Lightning Experience, the Salesforce mobile app, an Experience Cloud portal, or Slack—not unauthenticated external customers. Employee agents operate under the logged-in user's execution context. The user's profile, permission sets, and sharing rules/role determine the agent's actions and responses. It’s not necessary to explicitly scope queries and actions to user-specific data. User access to Employee agents is managed through permission sets or profiles.
Lead Nurturing Agent Execution Context Details
Agentforce Lead Nurturing agents are intended for top-of-funnel autonomous lead engagement. They can operate 24/7, sending customized emails, booking meetings, and answering prospect questions. Lead Nurturing agents run as a dedicated EinsteinSDRAgent User, which is created and assigned system-level permissions during agent setup. Prospects are assigned to the agent by assignment rules, automated actions, or individual sales users.
Service Agent Execution Context Details
Agentforce Service agents are intended for customer-facing use cases and connect to enhanced Messaging channels, which support authenticated and unauthenticated external users. The agent’s data access and execution context depend on the channel and whether credential-based user verification is enabled.
- Generally, the agent’s data access and execution context is determined by an agent user—a unique user record for the agent with all of the permissions that the agent needs to do its job. The agent runs in the context of the agent user and respects the agent user’s profile, permissions, field-level security, and sharing rules.
- If you’re using Enhanced Chat v1 or Enhanced Chat v2 to deploy a Service agent to an Experience Cloud site, you can turn on credential-based user verification. When credential-based user verification is enabled, the agent runs in the context of the logged-in site user and respects the user’s profile, permissions, field-level security, and sharing rules.
When a Service agent runs in the context of the agent user, context variables (for
example, MessagingSesson.ContactId) are used to pass the customer’s
identity to the agent, but they don’t control data access. Without additional
configuration, the customer has access to all of the records that the agent user has
access to. You must proactively limit data access.
- Pass verified customer IDs into the custom VerifiedCustomerId
variable.
If you use the standard Customer Verification or Service Customer Verification subagents for user verification in your agent, the actions are configured to store the user’s ID in the
VerifiedCustomerIdvariable after their identity is successfully verified. If you don’t, you can create a custom agent action and an Apex class or flow to pass the verified ID to your agent and store it in theVerifiedCustomerIdvariable. - Explicitly scope Apex classes and flows called by standard and custom agent
actions to customer records (
WHERE ContactId = VerifiedCustomerId).Some standard actions support customer verification out of the box—for example, the Get Cases for Verified Contact action calls a flow that looks up the customer’s contact ID, checks it against the
VerifiedCustomerIdvariable, and uses the verified customer ID to scope its queries. However, you should carefully test and customize each action to meet your security needs. - Create filters (
VerifiedCustomerId is not None) to restrict access to subagents and actions to verified customers.
