💬 In plain words: A user needs two separate grants before an agent is useful to them. One lets them use the agent at all. The other lets the agent reach data. They fail in completely different ways. 📌 Example: A Meridian rep is granted every object the agent touches, but not Agent Access. The agent simply does not appear for them. Nothing is wrong with the data model. 🎬 Real-Life Example: The Agent Nobody Could Find The Old/Bad Way: An admin built an agent, activated it, tested it in preview, and told the team it was live. Nobody could see it — including the admin, outside preview. Why this fails: Agent Access is a separate grant inside a permission set. Building an agent does not grant you the right to use it. Preview bypasses this, which is exactly why the gap goes unnoticed. The New/Good Way: 1. In the permission set, find the Agent Access section. 2. Add the specific agent to the enabled list. 3. As...
⚡ 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:
- Give the agent user only the two standard Service Agent permission sets.
- Add one custom set granting exactly the objects its actions touch — read Contact, read Asset, create Case.
- Test as an unauthenticated visitor and try to reach another customer's record.
- 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.
• The 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.