What Agentforce Builder configures
Agentforce Builder is not simply a prompt box. Salesforce positions it as the place to build agents around topics, instructions, and actions. Topics define the job boundary. Instructions guide the agent inside that boundary. Actions give it a way to retrieve data or perform work through the capabilities your Salesforce organization exposes.
That structure is most useful when it matches the human job. A service agent who answers delivery-status questions needs different topics, records, and handoff rules from a sales-development agent. Avoid a catch-all “support” topic that lets the agent attempt a refund, entitlement change, and technical diagnosis under one vague instruction.
| Builder element | Support example | Review question |
|---|---|---|
| Topic | “Warranty evidence for a Service Cloud case” | When should the topic refuse or hand off? |
| Instruction | Ask for serial number and approved proof of purchase | Does it use current policy and avoid an outcome promise? |
| Action | Retrieve case fields or create a review task | Which permission, owner, and post-action check apply? |
| Data access | Case, contact, and approved knowledge | Is this the least access required for the job? |
Build one case workflow before adding more
Start by mapping the human flow. For a damaged-device case, the agent may read the case summary, locate the approved troubleshooting article, and draft a request for a serial number and photo. It should not claim a replacement is approved unless an authorized system and policy say so.
Then define the agent's action boundary. A read of a case and a draft response are not the same as a record update. For every action, document what happens if information is absent, if an API call fails, or if the policy is ambiguous. The record system—not the agent's fluent reply—is where you check whether the requested work happened.
Salesforce's Agentforce documentation is the primary source for the currently available builder, action, and testing features in your edition. Editions and entitlements change, so do not publish a copied price table or assume a capability is enabled in every organization.
Test the behavior and the record result
Use a controlled set of Service Cloud cases before release:
- A routine request with all needed fields.
- A case missing the serial number or proof needed by policy.
- An exception request that must reach a human reviewer.
- Conflicting or old knowledge that must not override the approved article.
- A tool failure or unavailable record.
- A request that attempts to override the agent's stated instructions.
Inspect whether the agent chose the right topic, used appropriate information, and requested only permitted actions. Then inspect the resulting case, task, entitlement, or connected-system state. A successful test conversation does not show that a downstream action was authorized or completed correctly.
Use eesel CLI for Salesforce-specific support follow-up
eesel is a ready-to-work helpdesk teammate, not a replacement name for Agentforce Builder. Its CLI gives a person, script, Claude Code, Codex, or Cursor JSON access to the same eesel workspace and teammate used in the dashboard. This is helpful when the Salesforce case workflow needs a separate support teammate to find an approved article, prepare a follow-up, or route uncertainty.
For example, before a Service Cloud team deploys a new warranty topic, ask a coding agent for a read-only eesel report: which sources are connected, whether the current device-installation guide has downloaded, and which instruction governs a Salesforce case with missing evidence. Do not let that report connect an account, change a permission, or enable automation.
With Node.js 18.17 or newer, select the exact teammate first:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
TARGET_EESEL_AGENT="paste-agent-id-or-name-here"
npx @eesel/cli status --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli integrations --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli instructions --agent "$TARGET_EESEL_AGENT"
After the support owner approves an updated Salesforce-case guide, dry-run the relevant supported write. Before a test chat, contain actions outside the test and review configured permissions. Then test a redacted case summary:
npx @eesel/cli new --name "Salesforce warranty case check" --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli chat "A Service Cloud case says a device fails after the latest firmware update, but it has no serial number. Cite the approved setup guide, list the evidence to request, and state when a human warranty reviewer must decide." --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli approvals --agent "$TARGET_EESEL_AGENT"
Review the citations, evidence request, and handoff. This tests eesel's support guidance, not the Agentforce topic. If a held action appears, inspect it before approval and verify the actual Salesforce case or connected-system result afterward.
The eesel Activity page lists work with filters for approved, rejected, and pending items.
Pick the tool by the work it owns
Use Agentforce Builder when you are configuring Salesforce topics, actions, and data access and can own their testing and operations. Use eesel for an approved helpdesk teammate and its support workflow. In both cases, start with a narrow job, test representative cases, and verify consequential results in the system that owns them.
Review a warranty case with eesel
Try eesel to give your support lead and coding agent access to the same teammate from dashboard and terminal. Inspect the warranty guidance, test a case with missing evidence, and review the handoff before widening its responsibilities.
Frequently asked questions
What is Salesforce AI Agent Builder?
Agentforce Builder configures an agent with topics, instructions, actions, and data. It does not remove the need to govern permissions and check real outcomes.
What are Agentforce topics and actions?
Topics organize the job. Instructions guide behavior, while actions invoke configured capabilities. Give each action an owner, permission boundary, and result check.
How do I build a Salesforce support agent safely?
Start with one narrow job, approved knowledge, least-privilege data access, and a handoff for exceptions. Test inputs, failures, and the effect on the record.
What should teams test in Agentforce Builder?
Test routine cases, missing fields, old knowledge, policy exceptions, tool failures, and attempts to override instructions. Inspect the response, request, and record separately.
