Agentforce: Agent Access vs Data Access

💬 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. Assign that permission set to the users, and to yourself.
4. Test outside preview, as a normal user.

The payoff: Two grants, two failure modes, both understood. Invisible agent means Agent Access. Unhelpful agent means data access.

Concept

• Grant one: Agent Access. Permission to use this specific agent.
• It lives in its own section inside a permission set, separate from object settings.
• Without it, nobody can use the agent — including the system administrator who built it.
• Grant two: Data access. Objects, fields, Apex classes, and Flows that the agent's actions touch.
• Without it, the agent appears and then cannot do anything useful.
• Learn to tell the two apart by the symptom: Invisible agent versus unhelpful agent.
• Preview inside Builder can mask the first problem, which is why you must test outside it.

User wants to use an agent ├─ Agent Access granted? no → agent is INVISIBLE └─ Data access granted? no → agent is USELESS (silent, polite refusals) Both needed. Different sections. Different symptoms.

🧠 Invisible vs useless. No Agent Access = you cannot see it. No data access = you can see it and it cannot help.

🧭 360 Card — Agent Access vs Data Access

Rule: Grant Agent Access and data access separately, and diagnose by symptom.

Gain: You stop confusing two unrelated problems that look similar from a distance.

Price: Two things to remember on every rollout instead of one.

Limits: Agent Access is per agent. Adding a second agent means a second grant.

Mirror — assuming admin can always use it: Building an agent does not grant you the right to use it.

Later: On rollout, this is your first support ticket. Prepare the answer before go-live.

Core Q&A

Q: You built and activated an agent, but nobody can see it. What is wrong?

🎯 Say this first: Agent Access. It is a separate grant inside the permission set, and building the agent does not give it to you.

A: This is a grant problem, not a build problem.

• Using an agent requires Agent Access, which sits in its own section of a permission set.
• It is separate from any object or field permission, and it is per agent.
• Without it, the agent does not appear, even for the administrator who created it.
• Preview inside Builder still works, which is exactly why the gap survives testing.
• The fix is to add the agent to the enabled list in a permission set and assign it, including to yourself.
• Then test outside preview as an ordinary user, because that is the only test that proves anything.

📝 2-Minute Self-Check

Q1. Which agent type uses default_agent_user?

A1. Service Agent. It is ignored for an Employee Agent.

Q2. The agent says it cannot find a record that exists. First place you look?

A2. The permissions of the user it runs as. The failure is silent.

Q3. An agent is invisible to every user including the admin. Cause?

A3. Agent Access has not been granted in a permission set.