Agentforce: Agent Types & Execution Identity

⚡ 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 with its own dedicated user.

🎬 Real-Life Example: The Agent That Could See Everything

The Old/Bad Way: A team built a customer-facing agent, gave its user a broad permission set "so it works", and shipped it.

Why this fails: A Service Agent has its own user. Whatever that user can read, every anonymous visitor can reach through conversation. Broad access on the agent user is broad access for the public.

The New/Good Way:

1. Give the agent user only the two standard Service Agent permission sets.
2. Add one custom set granting exactly the objects its actions touch — read Contact, read Asset, create Case.
3. Test as an unauthenticated visitor and try to reach another customer's record.
4. Fix the permission set, never the prompt.

The payoff: The agent cannot leak what it cannot read. Prompt wording becomes irrelevant to security.

Concept

• Employee Agent serves internal users, in the Agentforce panel in Lightning, Slack, and the Salesforce mobile app.
• Service Agent serves customers, in web messaging, Experience Cloud, WhatsApp, SMS, email, and voice.
• The execution identity differs, and that is the whole point.
• An Employee Agent operates with the permissions of the person talking to it. There is no separate agent user.
• A Service Agent uses its own dedicated user, which you configure and which starts with almost nothing.
• In Agent Script, agent_type is either AgentforceEmployeeAgent or AgentforceServiceAgent. It defaults to Service if you leave it out.
• default_agent_user is required for a Service Agent and ignored for an Employee Agent.

Agent type ├─ Employee → runs as the LOGGED-IN USER (no agent user) │ channels: Lightning panel, Slack, mobile └─ Service → runs as its OWN USER (default_agent_user) channels: web chat, site, WhatsApp, SMS, voice Both: FLS + sharing always apply. No back door.

🧠 Employee BORROWS, Service OWNS. Employee agents borrow the caller's badge. Service agents carry their own.

🧭 360 Card — Employee Agent vs Service Agent

Rule: Pick the type by who is talking, then design permissions for that identity, not for yourself.

Gain: The security model becomes obvious. You always know whose access is the ceiling.

Reach for: Employee Agent when staff are the users and their existing permissions are already correct. Service Agent when the public is involved.

Price: A Service Agent is more setup — its own user, two standard permission sets, then your custom one.

Limits: 20 active agents per org. agent_type defaults to Service if unset.

Mirror — one agent for both audiences: Not possible in any safe way. The identity model is different, so the permission design is different.

Later: This decides your testing plan. Employee agents are tested as a restricted employee. Service agents are tested as an anonymous visitor.

At volume: Service agent permissions get audited hardest, because every grant is public reach.

⚠ INTERVIEW TRAP: Do not say "the agent has its own user" as a general statement. That is only true for Service Agents. Saying it about Employee Agents is the fastest way to show you have not built one.

Core Q&A

Q: What is the difference between an Employee Agent and a Service Agent?

🎯 Say this first: Audience and identity. Employee agents run on the logged-in user's permissions. Service agents have their own dedicated user.

A: Start with the audience, then move to identity, because identity is what actually matters.

• Employee agents serve internal staff, in the Lightning panel, Slack, or the mobile app.
• They operate with the permissions of whoever is talking to them, so there is no separate service account.
• Service agents serve customers across web messaging, Experience Cloud, WhatsApp, SMS, and voice.
• They run as their own dedicated user, which you configure and which begins with essentially no access.
• In script, default_agent_user is required for a service agent and ignored for an employee agent.
• Design consequence: For an employee agent, tightening security means tightening the user's permissions. For a service agent, it means tightening the agent user and the guest profile.

Follow-ups (Scenario-Based)

Q1: Your Employee Agent works for you and fails for a support rep. Where do you look?

A1: The rep's permissions, because the agent is running as them.

• You are almost certainly an administrator, so your test proved nothing about their access.
• Check object and field access for everything the agent's actions touch, plus Apex class and Flow access.
• Also check Agent Access — the rep may not be granted the agent at all, which fails differently.
• Common mistake: Rewriting the instructions. The prompt is not the problem.

Q2: How would you design permissions for a public-facing Service Agent handling outages?

A2: Least privilege, and prove it by test.

• Assign the agent user the two standard Service Agent permission sets, then one custom set on top.
• That custom set grants only what the actions need — read Contact, read Asset, create and read Case.
• No Account read, no Contract read, nothing added speculatively.
• Then test as an anonymous visitor: ask for another customer's case, ask for a phone number, and try a direct instruction override.
• If any of those succeed, fix the permission set. Never fix it in the prompt.