Running-user permissions and sharing for actions
Key Takeaway
Every agent action runs as a specific Salesforce user whose access decides what the action can read or change. A Service agent runs as its dedicated agent user unless credential-based user verification is enabled, so scope its actions to the verified customer's records.
Every action an Agentforce agent takes runs as a specific Salesforce user, whose profile, permissions, field-level security, and sharing rules decide what the action can read or change. Which user that is depends on the agent type, the channel, and whether credential-based user verification is enabled. If the running user is configured wrong, the agent either fails to answer or exposes data it shouldn't.
Who the agent runs as
The execution context varies by agent type, by channel, and by whether credential-based user verification is enabled.
| Serves | Runs as | |
|---|---|---|
| Agentforce Employee agent | Internal users | The logged-in end user |
| Agentforce Service agent | Customers on Messaging channels | A dedicated agent user, EinsteinServiceAgent User |
| Agentforce Lead Nurturing agent | Leads and prospects, by outbound email | A dedicated EinsteinSDRAgent User |
Employee agents work in Lightning Experience, the Salesforce mobile app, Slack, or Enhanced Web Chat on an Experience Cloud site. Because the user's own profile, permission sets, and sharing rules or role decide what the agent can do, you don't need to scope queries and actions to that user's data.
Service agents connect to Messaging channels that aren't restricted to logged-in users, so they can't rely on an end user's record. The agent user's profile, permissions, field-level security, and sharing rules decide what every customer in the conversation can reach.
The EinsteinSDRAgent User is created and given system-level permissions during agent setup. A Lead Nurturing agent knows who it is talking to from the lead or contact context.