Employee Agent

💬 In plain words: An agent can only do what its user can do. Field-level security applies, sharing rules apply, and there is no override. The only question is which user, and that is decided by the agent type. 📌 Example: A Meridian rep asks the Employee Agent about a meter on an account they cannot see. The agent says it cannot find it. The meter exists — the rep just has no access. Concept This is the single most useful fact in Agentforce, and the most commonly got wrong. Employee Agent: Runs as the logged-in user. Service Agent: Runs as its own dedicated user ( default_agent_user ). Field-level security (FLS) is enforced normally. Sharing rules are enforced normally. Apex actions inherit this through with sharing and WITH USER_MODE queries. The failure mode is silent. There is no error, no exception, and no error banner. The agent simply says it cannot help, in a perfectly polite sentence. That s...

⚡ 1-Minute Summary Employee Agents run with the logged-in user's permissions. Service Agents have their own user. default_agent_user is required for a Service Agent and ignored for an Employee Agent. Two separate grants: Agent Access to use the agent, data access to reach the records. Module map MODULE 1 root: 'Which user is this agent, and what may it touch?' ├─ 1.1 Employee Agent vs Service Agent ├─ 1.2 Which user the agent runs as ├─ 1.3 Agent Access vs data access └─ 1.4 Designing permissions for agents Employee Agent vs Service Agent 💬 In plain words: Two agent types. One serves your staff, one serves your customers. The difference is not the skin — it is whose permissions the agent borrows, and that changes how you secure everything. 📌 Example: Meridian has two. The call-centre panel in Lightning is an Employee Agent. The chat window on meridianpower.com is a Service Agent...