Agentforce Integration: Data Prerequisites, Use Cases and Project Timeline

The demo went well, and the decision in principle has been made. The practical question remains: what needs to be prepared for Agentforce to work in your organization, where to start, and who can do it?

The answer starts with what the agent will read. It knows nothing about your company beyond what your Salesforce org contains, and it restates it with total confidence: if the record shows an active contract that has in fact been terminated, it will tell the customer without hesitation. This article therefore starts with the data.

What an Agentforce integration covers

Agentforce plugs into your org, not alongside it

Agents live in your org and use its objects, permissions and automations. What they can do is described on our Agentforce page; here, we focus on how they are implemented in your organization.

An agent is configured through subagents — the tasks it handles, called “topics” until April 2026 — and through actions — what it can do: find an order, create a case. These actions rely on what already exists in the org: flows, Apex code, prompt templates. Integrating means connecting an agent to data and processes you already have.

What an integration agency does

• Scoping. The process entrusted to the agent, and its limit.
• Data. Identifying the objects the agent reads, measuring their condition, fixing them before launch.
• Actions. Connecting each action to an existing flow or rule, rather than recreating the logic inside the agent.
• Testing. Replaying real requests and adjusting the instructions.
• Go-live. Starting small, reading the conversations, expanding.

What it does not replace

The business owner of the process. The agency writes the instructions, but cannot decide on its own what a customer is entitled to or when an advisor takes over the conversation. Without a named owner, the agent inherits the process’s grey areas and settles them depending on how each request is worded.

Data prerequisites

The objects the agent reads, by use case

• Tracking a request. Cases, related accounts and contacts, and the knowledge articles that explain lead times and procedures.
• Lead qualification. Leads, existing accounts and assignment rules.
• Booking appointments. Contacts, calendars and availability rules.
• Updating a record. The modified object itself, and the fields that trigger downstream automations.

An agent never reads “Salesforce” in general, but a handful of objects and fields: preparation covers this scope, not the entire database.

Four defects that lead to wrong answers

• The empty field. The contract end date is missing: the agent does not answer, or infers an answer from another field.
• The outdated field. The status stayed “Active” after termination: the agent announces a contract that is still running.
• The duplicate. Two accounts for the same customer: the agent reads the first and ignores the open cases on the second.
• The overly broad permission. The agent sees a negotiated discount or an internal note, and nothing stops it from quoting it.

Your teams work around these defects every day. The agent does not work around them: it reads.

An advisor is wary of a suspicious record; an agent recites it.

The agent’s permissions and scope

A customer service agent acts with the permissions of a dedicated user, created with minimal access, to which permission sets are assigned. This is the lever for limiting what it sees and modifies: a request-tracking agent has no reason to read opportunities. The default rule: the minimum, extended on request.

Salesforce’s safeguards, such as zero data retention by the model provider or the audit trail, do not replace this setting: they protect the conversation, not your permission model. Data masking for sensitive data, for its part, is disabled for agents.

The role of Data 360, formerly Data Cloud

Salesforce requires Data 360 — the new name for Data Cloud — to be provisioned in the org before Agentforce can be activated. As long as the agent answers from Salesforce objects and your knowledge articles, the issue remains the quality of those objects. Data 360 takes on a central role when the agent relies on broader sources: documents, ERP data, a customer’s history spread across several systems. What your contract includes depends on your licenses and changes over time: check with Salesforce.

Data 360 unifies data, it does not correct it: a wrong address in the ERP stays wrong once it has been brought in.

A data foundation before the agent

That is the job of turnK, the company in our group dedicated to making data reliable. At Mirakl, the team cleaned up duplicates and outdated information, fixed the synchronization between HubSpot and Salesforce, then put lasting governance rules in place. It was not an Agentforce project, but it is exactly the foundation an agent needs.

Is your Salesforce data not ready? turnK makes it reliable.

Choosing the first use case

The module at the top of this article makes this choice for your situation. Here is the reasoning behind it.

Start with a frequent, well-defined, reversible request

• Frequent. It comes up often enough for a pilot to quickly produce conversations to read.
• Well-defined. The right answer is written down somewhere — a procedure, a status, a rule — and does not depend on judgment.
• Reversible. If the agent gets it wrong, the error can be fixed without harm: a piece of information to correct, an appointment to move, not a refund issued.

An often-forgotten criterion: for comparable value, pick the use case whose records are already kept up to date.

Customer service: tracking an open request

“Where is my request at?” The agent finds the case, reads its status and explains the next step using a knowledge article. To check: case status, the link to the right contact, articles on lead times. The key question: is the status updated at every step, or only at closure? In the second case, the agent will answer “in progress” until the last day.

Sales: qualifying inbound leads and booking meetings

A lead comes in through a form. The agent asks the qualification questions, checks whether the company is already a customer and offers a slot with the right sales rep. The most costly defect is the duplicate: an existing customer requalified as a prospect gets a discovery pitch, and their sales rep knows nothing about it.

What is better kept for later

• Irreversible actions. Refunding, terminating, deleting: until the agent has proven itself, a human approves.
• Commercial gestures. A discount commits the company, and its rule is rarely documented well enough.
• Sensitive data. Health, banking, HR: the legal framework is settled before the pilot.

How an integration unfolds

Two tracks in parallel, data and the agent, which meet before opening to customers.

Scope the process and the agent’s limit of action

A few written decisions: the process entrusted to the agent, the requests it refuses, the actions it carries out, the point at which it hands over. This is the document you reread when an answer is surprising.

Check and fix the data it uses

You list the objects and fields the agent reads, then measure them: fill rate, date of last update, duplicates, permissions. What is wrong gets fixed; what degrades is assigned to an owner. A status no one is responsible for maintaining will become wrong again.

Build actions from existing flows

If a flow already creates a case or reschedules an intervention, the agent’s action should call it, not rewrite it: when the rule changes, the agent and the advisors change together. Along the way, spot obsolete automations, to be deactivated before an agent triggers them.

Test on real conversations and plan the escalation

Testing is done on requests actually received, with their typos and changes of subject, not on the demo scenarios. For each answer: the data read, the action triggered, the tone. The escalation is tested too: when the agent does not know, the conversation lands in an identified queue, with its history.

Pilot on a reduced scope, then expand

First launch internally, for advisors, or on a single channel and a single type of request. You read the conversations, fix things, then open it to customers. You then expand topic by topic, going back through the data each time.

You do not open the agent to customers until its data has been checked.

Choosing an Agentforce agency

Agency demos look alike; their methods much less so.

Questions to ask

1. What do you do with our data before building the agent? A serious answer names objects, fields and a checking method.
2. Which conversations do you test on? Yours, actually received, or scenarios written for the occasion.
3. Who stays in control of the answers? Who changes the instructions after go-live.
4. How do you measure? Which indicators, recorded before launch, will allow comparison afterwards.

Warning signs

• A demo without your data. It tells you nothing about what the agent will do in your org.
• No plan for the data. The schedule goes straight from scoping to building: preparation is assumed to be done, or left to you.
• A quantified gain promised in advance. No one can announce a resolution rate before looking at your requests and your records.

At StackEasy, we support Agentforce projects by starting there: the objects the agent will read, their condition, what needs fixing. When the data workstream goes beyond the agent, turnK takes over.

Where to start

Not with choosing licenses. With a single process and a short assessment: the most frequent request in your customer service or sales team, the objects it involves, their actual condition, and the person who will take over when the agent does not know. This work makes the project possible to price and protects the launch against a confident answer based on an outdated record.

To go further: what an AI agent is and how it works in business, how to fix duplicates without recreating the problem, or browse our Salesforce page.