A technician in Slack asks the Employee agent to pull up a colleague's HR-adjacent internal note, and the technician's own Slack identity happens to have broad channel visibility in Slack itself. Does the technician's Slack-level access expand what the agent's underlying action is allowed to retrieve from Salesforce?
Select an answer to reveal the explanation.
Short Explanation
Whatever doors the technician can open in Slack is a Slack question. What the agent's action can actually pull out of Salesforce is still decided entirely by the Agent User's own badge, and Slack has no way to hand that badge extra keys.
Full Explanation
Regardless of which channel a conversation arrives through, an agent's actions execute in the security context of the Agent User, whose permission set is configured independently in Salesforce; the requesting human's access within the channel application itself, here Slack channel visibility, has no mechanism for expanding what that action can retrieve. This is the same principle already established for other channels: the human's local identity or visibility in the channel tool is not the acting identity for the underlying data operation. There is no automatic synchronisation between Slack channel membership and an Agent User's Salesforce permission set; the two are entirely separate systems, and inventing such a sync is exactly the kind of unsupported feature claim the exam penalises. Being a System Administrator in Salesforce is a property of the technician's own user record and has nothing to do with what the Agent User, a completely different record, can retrieve on their behalf. The Einstein Trust Layer masks sensitive data flowing to and from the model and has no role in expanding or restricting object- and field-level data access; its enabled state on a workspace does not change who the acting user for a Salesforce query is.