Agentforce demos look effortless. An agent receives a customer request, reasons through the options, and resolves it — all without a human in the loop. It feels like magic.
Then you try to build one yourself and realise the magic has a lot of configuration behind it.
The good news: setting up your first Agentforce agent is genuinely achievable, even if you're new to the platform. The bad news: most teams rush the first deployment and create a mess they spend months cleaning up. This guide is the path that avoids that.
Step 1: Define the Agent's Scope Before You Touch Setup
The number one mistake I see is starting in Setup before the team has agreed on what the agent is actually supposed to do.
Agentforce agents are scoped to a topic — a defined domain of questions or tasks they're authorised to handle. If you haven't defined the boundary clearly, you'll build an agent that either does too much (and causes errors) or too little (and frustrates users).
Before clicking anything, write down:
- What the agent is authorised to do (e.g., "answer billing questions, update contact details")
- What it must escalate to a human (e.g., "refunds over £500, account closures")
- What it should never touch (e.g., "opportunity data, financial records")
This becomes your agent's topic configuration, and it's also your acceptance criteria for testing.
Step 2: Build and Test in a Sandbox First — Always
This should be obvious, but it bears repeating: never build your first Agentforce agent directly in production.
Use a Full or Partial Copy sandbox with data that reflects your production org's complexity. A Developer sandbox is fine for exploring the UI, but it won't surface the edge cases that matter — like what happens when an agent encounters a contact record with missing fields, or when a Flow that the agent triggers fails mid-run.
Enable the Agentforce preview in your sandbox settings, then build there completely before promoting anything.
Step 3: Set Up Data Access Permissions Carefully
Agentforce agents operate under a specific user's permissions — typically a dedicated Integration User or Agentforce System User profile. This profile defines exactly what objects, fields, and records the agent can read or write.
The default setup is more permissive than most teams realise. I've seen agents inadvertently granted access to sensitive fields — compensation data, contract values, internal notes — simply because the integration user profile was cloned from an admin.
What to do instead:
- Create a dedicated profile or permission set for your agent
- Start with minimum required access — only the objects and fields the agent's topic genuinely needs
- Add access incrementally as you test, not all upfront
Step 4: Configure the Topic and Actions
In Setup, navigate to Agents and create your agent. The key building blocks are:
- Topics: what the agent is allowed to discuss and handle
- Actions: the specific operations it can perform (query records, create cases, send emails, trigger Flows)
- Instructions: natural language guidance on how the agent should behave within a topic
Keep your first agent's action set small. One or two actions are much easier to debug than five. You can expand the action library once the core is working reliably.
Step 5: Test with Real-World Edge Cases
The happy path always works. What matters is how the agent handles the edge cases.
Build a test script that includes:
- Requests that are in scope — expect resolution
- Requests that are out of scope — expect clean escalation, not an error
- Incomplete or ambiguous inputs — expect clarification, not guessing
- Boundary cases (e.g., "I want to cancel" — is this billing or churn?)
Run every scenario before promoting to production. Document what you expected vs. what happened. This becomes your regression test suite.
Step 6: Roll Out to a Pilot Group First
When you're ready to go live, don't flip the switch for everyone at once.
Release to a small pilot group — ideally 10–20 users who understand they're testing a new system. Collect structured feedback for two weeks. Look at:
- Escalation rate (high = agent scope is too narrow or instructions are unclear)
- CSAT on agent-resolved tickets vs. human-resolved
- Any errors or unexpected behaviours logged in the Einstein Activity Log
Only expand rollout once your pilot metrics look stable.
MeetTheMind Insight 💡
The teams that succeed with Agentforce aren't the ones who deployed fastest. They're the ones who defined the tightest scope first.
An agent that handles 200 requests a day and resolves 85% of them reliably is worth ten times more than an agent that handles 2,000 requests and creates noise for your support team. Narrow + reliable beats broad + unpredictable every time — especially for your first deployment.
Key Takeaways
- Define the agent's topic, escalation rules, and off-limits areas before touching Setup
- Always build and test in a Full or Partial Copy sandbox
- Use a dedicated permission set with minimum required access — don't clone from admin
- Keep your first agent's action set small and expand incrementally
- Test edge cases and failure modes, not just the happy path
- Roll out to a pilot group before opening to everyone