Agentforce Service

A customer tells a Service agent who they are. The agent verifies the customer, finds a booking and changes the booking. Three separate questions sit inside that exchange: who the customer is, whose permissions execute the action, and what shows the right record changed.

Verification answers the first. In Salesforce’s Coral Cloud sample, the agent emails a code, checks the code, and stores a verified customer ID. The booking action takes its customer field from that ID instead of from whatever the customer types, so a request naming someone else shouldn’t redirect the booking.

The second question has a different answer. Salesforce’s docs say agents on channels that aren’t limited to logged-in users, such as Messaging, operate in the context of an agent user: a Salesforce user record with the permissions the agent needs. The customer may have no Salesforce access at all. The agent user’s access isn’t the customer’s entitlement, so the builder has to connect the verified identity to the right records.

Execution context adds another layer. Salesforce’s Verify Customer action runs its flows with elevated system-context permissions, because the lookup happens before anyone is verified. For custom Apex actions, Salesforce recommends explicit sharing and user-mode data operations, and Flow’s debugging docs warn that system-context flows ignore the selected user’s object and field access. An action named “Create Booking” reveals none of this; the implementation behind the name does.

Salesforce’s newer customer-support example even ships a verification stub that lets any code pass, for trying the interface. A polished preview can demonstrate the conversation and prove nothing about identity.

For builders: write the authority map down, covering customer identity, agent user, action, execution mode and affected record. “Respects permissions” is too vague to stand in for the map.