Salesforce Agentforce orchestration planning guide.

Salesforce Summer ’26 adds Agentforce multi-agent orchestration. Here is what admins should review before testing agents across records, queues, and systems.

Salesforce Summer ’26 puts Agentforce multi-agent orchestration on the admin roadmap. That matters because orchestration changes how work moves across agents, users, records, permissions, queues, and external systems.

Salesforce says the Summer ’26 Release is available June 15, 2026. The announcement lists Multi-Agent Orchestration in Agentforce as one of the top updates. Salesforce describes it as a way for agents to work together on complex workflows, with shared context across channels.

That is useful. It is also not a feature to enable without a design pass.

What is Agentforce multi-agent orchestration?

Agentforce multi-agent orchestration means one request can be handled by more than one specialized agent.

A customer service example is easier than a definition. A customer asks about an order delay. One agent identifies the customer, reviews the Account and Contact, and checks recent Cases. Another agent checks order status in an external system. A third agent drafts a response, creates a Task, or routes the Case to a human queue.

The goal is not to make one agent responsible for everything. The goal is to coordinate agents that each have a defined role, defined data access, and a defined handoff point.

Salesforce’s release material describes this as a way to give the customer a single point of contact while agents share context behind the scenes. Admins should focus on that shared context. Shared context helps only when the underlying data model, permissions, and escalation paths are clear.

For mid-market teams, Agentforce moves from a single-use assistant into a workflow design question. The admin question is no longer, “Can the agent answer this?” It becomes:

• Which agent should act first?
• Which records can the agent read?
• Which fields can the agent update?
• Which system can the agent call?
• When should the agent stop and send work to a human?

Those questions belong in the design, not in production troubleshooting.

Why should Salesforce admins plan now?

Summer ’26 is not only a feature release. It changes how admins should plan AI inside Salesforce.

Single-agent use cases can often be tested in one narrow area. Examples include summarizing a Case, answering a Knowledge question, or drafting an email from a Contact record.

Multi-agent workflows touch more surface area. A single request may cross Service Cloud, Sales Cloud, Slack, Data 360, Flow, Experience Cloud, custom objects, and external systems.

That creates real admin work:

• Agent roles need clear boundaries.
• Agent instructions need version history.
• Object and field access need review.
• Escalation paths need named queues and owners.
• Tests need multi-step scenarios, not single prompts.
• Reporting needs to show what happened, not only the final result.

Salesforce Help also documents how admins can create and manage multiple versions of an agent. That matters. Versioning gives teams a safer way to test, troubleshoot, and adjust agent behavior without editing the active version each time.

Versioning does not replace governance. It gives admins a control point.

Where does Agentforce orchestration fit first?

Mid-market companies usually do not have a large Salesforce platform team. One admin may own Sales Cloud, Service Cloud, integrations, reporting, user support, and release management.

That makes orchestration useful, but it also raises the cost of unclear design.

The best first use cases are narrow, structured, and measurable. Good candidates include:

• Case triage by product, region, customer type, or account tier.
• Knowledge article lookup before human escalation.
• Renewal preparation for account owners.
• Internal IT or operations requests with defined categories.
• Appointment or callback routing based on structured fields.
• Case enrichment using Account, Contact, Entitlement, and prior Case data.

Poor first use cases have unclear ownership or undocumented judgment. If two experienced users cannot agree on the correct next step, an agent should not be asked to decide it.

A practical test is simple. Write the current human process in numbered steps. If step 4 says “review and decide what to do,” the workflow is not ready. Replace that sentence with criteria the agent can apply, or keep the step with a human owner.

What Salesforce admins should check first

Before piloting Agentforce orchestration, review five areas.

1. Object and field access

List every object and field each agent needs.

For Service Cloud, that may include:

• Case
• Contact
• Account
• Knowledge
• Entitlement
• Task
• EmailMessage
• Related custom objects

Start with least access. Do not give an agent broad access because the process is not mapped. That is a design gap, not a permission requirement.

Also review field-level security. An agent may need access to Case Priority, Status, Origin, Reason, and OwnerId. It may not need access to sensitive Contact fields, financial fields, or internal notes.

2. Record ownership and queues

Every orchestrated workflow needs a clear end state.

If a request cannot be completed, where does it go? Check:

• Case assignment rules
• Omni-Channel routing
• Queue membership
• Escalation rules
• Task ownership
• Notification paths

A failed handoff should create visible work for a human owner. It should not disappear into an activity log or an agent transcript that no one reviews.

For Service Cloud, test this with real queue names and realistic Case statuses. “Escalate to support” is not specific enough. “Route to billing support queue with Status = Escalated and Priority = High” is better.

3. Agent instructions and versioning

Use agent versioning as an operating control.

Keep a change log for each agent version:

This is not paperwork for its own sake. It prevents mystery behavior after a prompt or instruction change.

4. Flow and integration behavior

If an agent calls Flow or an external system, define failure behavior before users see the workflow.

For example, an order status agent should know what to do when the order system:

• Times out
• Returns no matching order
• Returns multiple matching orders
• Returns incomplete data
• Returns an error code

The answer may be retry, create a Task, update a Case field, or route to a queue. The important point is that the fallback is designed.

This is where many pilots get noisy. The agent is blamed for a workflow problem that already existed in Flow, middleware, duplicate data, or external system ownership.

5. Reporting and audit

Decide how success will be measured before rollout.

Useful measures include:

• Cases routed without reassignment
• Requests escalated to humans
• Agent handoff failures
• Average time to first useful response
• Records updated by agent action
• User overrides or corrections
• Cases reopened after agent involvement

If reporting is not ready, the pilot will be judged by anecdotes. That makes it harder to know whether orchestration improved the workflow or only moved the work to a less visible place.

How to test Agentforce orchestration in sandbox

Use a sandbox first. Test with realistic record shapes, not perfect demo data.

A useful test set should include:

• Missing Contact phone numbers
• Duplicate Contacts
• Closed Cases
• Stale Entitlements
• Accounts with multiple open Cases
• Cases without a Product value
• Records owned by inactive users
• External system errors
• Knowledge articles with outdated content

Run tests as users with different profiles and permission sets. An admin test is not enough. The agent should be evaluated under the same access model the production user will have.

Also review the main Salesforce Summer ’26 release notes before enabling anything in production. Edition availability, rollout timing, and feature details can vary by org.

What to do this week

Pick one workflow with high volume and low ambiguity.

Write the current human steps. Name the Salesforce objects, fields, queues, Flows, and external systems involved. Mark where a human judgment call is still required. Then decide whether one agent is enough, or whether orchestration is warranted.

Do not start with every Summer ’26 AI feature. Start with one workflow that can be tested, measured, and rolled back.

Agentforce orchestration is a workflow architecture decision. Treat it like one.