💬 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...
💬
In plain words: One example company runs through this whole
notebook: Meridian PowerPack, an electricity utility. It sells power, reads meters,
fixes outages and sends bills. Every module retells one part of that business
as an agent problem.
📌
Example: Follow one outage. A customer reports it.
The agent checks whether the meter is theirs. It looks up the
outage map. It creates a case. It refuses to
promise a restore time.
Concept
• The household or business that buys power =
Account. The person who calls = Contact.
• Each electricity meter = Asset. Its tariff
plan = Contract.
• A reported outage or bill dispute = Case. A
crew visit = Work Order or Task.
• A rule like "never quote a restore time that is not confirmed" = a check in after_reasoning.
• The engineer manual PDFs the agent quotes
from = a Data Library.
• The chat window on meridianpower.com = a
Service Agent.
• The panel the call-centre staff use in
Lightning = an Employee Agent.
• The billing system that holds the actual invoice = an External Service or MCP tool.
🧠 One outage, whole platform: to revise any module fast, retell it as a Meridian story. What happens to the outage here?
🧭 360 Card — Meridian Power — Our Running Example
Rule: use one running example everywhere. Consistency beats variety when you are memorising.
Gain: you can answer any question with a concrete story instead of an abstract definition.
Price: a made-up company is not proof you built anything. Pair it with something you actually shipped.
Limits: none technical. This is a study device.
Mirror — a fresh example per topic: more interesting to read, much harder to recall under pressure.
Later: in an interview, swap Meridian for the client you actually worked for. The structure carries over.
Core
Q&A
Q:
Give me an example of a good Agentforce use case and a bad one.
🎯 Say this first: Good: an outage call, where the words vary wildly. Bad: the nightly
billing run, where nothing varies.
A: Use Meridian to make it concrete.
• Good use case: a customer reports an outage.
They might say "power cut", "no electricity", "lights
are off", or "the whole street is dark".
• The words vary, the intent is one thing, and
the agent needs to check entitlement and create a case.
• Bad use case: generating three million bills
every night. The steps never change and the input is structured.
• That is Batch Apex. Putting it behind an
agent would be slower and cost credits for nothing.
• The dividing line is not difficulty. It is
whether the input is unpredictable language.
Follow-ups
(scenario-based)
Q1: The business wants one agent to handle
outages, billing, tariffs, meter readings, complaints and new connections. What
do you say?
A1: Push back on the shape, not the ambition.
• That is six domains. Each needs several
subagents, and the ceiling is 15 per agent.
• Routing accuracy also falls as descriptions
crowd together, and the failure is invisible.
• The answer is one agent per domain, or an
orchestrating agent that delegates to specialist agents.
• Common mistake: agreeing, building one giant
agent, and discovering the ceiling three sprints in.