How to align sales and service teams using Agentforce data

A customer asks service whether a quote is still open. The service agent says there is not one, because it never read Opportunities, and the customer then tells their seller that service denied the deal. The same morning, a sales agent books a renewal call on an Account whose highest-severity Case is still open, because it never read Cases. The seller walks into a conversation the customer experiences as indifference. Both replies were fluent. Both were missing the other team's object.

Sales and service fall out of step when each team's agent can see only its own object. The fix is not one agent that can see everything and do both jobs. The fix is a timeline both can read, a payload when work crosses, and two action lists that cannot write across the boundary.

Salesforce describes agents as answering from trusted business data, including CRM data. Use that for a shared timeline, not for a shared job. One Account, the open Cases, the open Opportunities, and a payload when work passes between the teams. Two subagents. Two action lists. The way those subagents get built, and why a shared library fails, is a custom copilot is one job. This page is what the two jobs owe each other.

#One timeline

The timeline is the Account and the records already hanging off it. Service instructions should say: before you answer about commercial terms, read open Opportunities on this Account and do not contradict them. Sales instructions should say: before you recommend a next step, read open Cases and do not ignore a live incident. Reading is the alignment. If the read is missing, the reply will invent a quieter Account than the one the customer is living in.

Say which record wins when several are open. The latest open Opportunity is not always the one the customer means. A renewed quote and an expansion quote can both be open, and "the latest" may be the one a colleague touched this morning for an internal reason. Prefer the one the person named. If they named a product, match that. If they did not name one, say there are two and ask, or hand off. Do not blend the amounts into a sentence that describes a deal you do not have. A blended brief reads cleanly and refers to nothing on the record.

The same rule applies to Cases. "The Case" is ambiguous when two are open. Prefer the one the customer named, or the one whose number they gave. If they gave neither, say there are two and ask. A sales next-step that ignores a severe Case because a minor Case was newer is the timeline being read badly, which is a different fault from the timeline not being read at all. The instruction has to say which one, not merely that Cases exist.

Permissions still apply. A sales running user may not see every Case, and a service running user may not see every amount. Do not fix alignment with View All. If a user should not see a field, the agent running as that user should not quote it, and it should not infer it from a neighbouring field it can see. Put shareable facts into the handoff payload that the receiving team is allowed to read. A payload is a deliberate disclosure. View All is an accident that will also disclose the fields you did not mean to share.

#A handoff payload, not a mood

When work crosses teams, write a payload onto the record. Include Account Id and Contact Id. Include the open Case numbers that were actually discussed, not every Case on the Account. Include the Opportunity name and stage if one was discussed, and the Id, so the next person does not attach the note to the other open deal. Include what the person asked, in their words. Include what action already ran, and what the agent refused to do. Name the queue or the user who received it.

A note that only says "please assist" forces the next person to start again. They will ask the customer to repeat the commercial question, or they will open the wrong Opportunity and answer it. The customer hears their own story twice and loses confidence that the two teams share an employer. The payload is how you avoid that without giving either agent the other's write permissions.

Beyond scope, the agent stops. A commercial exception in a service chat is a handoff, not a discount the service agent invents to keep the chat short. A service complaint in a sales conversation is a handoff, not a promise that "someone will sort the outage" with a time the service queue has not offered. Salesforce's line is that agents escalate when the issue is beyond their scope. The scope here is the job of the subagent, not the mood of the Account. Helpfulness across the boundary is the defect.

The refusals have to be in the instruction the plan sees on every turn. An employee who pastes the policy into the utterance is not the user you will have next week. Write the refusal on the subagent, and test with an utterance that only contains the customer's request.

#Two jobs, two libraries

One agent with both jobs will have both action sets. The plan will close a Case while helping a seller, or edit an Opportunity while helping service. The sentence will explain the write as though it were part of being thorough. Split them. The service subagent's library has no stage edit and no amount edit. The sales subagent's library has no Case close and no Case field that service automation already owns.

They may both read the timeline. Reading is the alignment. Writing across the boundary is the defect. An instruction to "help the whole customer" invites that write even when you built two subagents, because the phrase has no objects and no stop. Name the job. Name the refusals in the same instruction. If a new action is proposed, ask which job it serves. An action that serves both is two actions, and it does not belong in either library until you have split it.

There is a tempting middle, a single agent with instructions that say "do not write the other team's fields". Instructions are weaker than an absent action. The plan can still call an action that is in the library, and a fluent trace will look like an exception you meant to allow. Absence is the control. If the action is not there, the write cannot happen, and you do not have to catch it in a sample.

The table is the design review. A library that cannot be described by one row is already two jobs.

#Stage edits are a rule

Opportunity stage is an exit criterion. Required fields. An approval where you use one. A definition your forecast depends on. The agent may say a deal looks ready for the next stage. A person or a Flow commits StageName. A model guess that writes the field will be treated as fact by the next report, and people will act on the number before anyone notices the required fields are blank.

Positive activity is not an exit criterion. A meeting happened. An email was warm. The customer said they were keen. None of those check the fields the forecast assumes are present. The helpful failure is a sales copilot that advances three Opportunities because the last activity was positive. The forecast moves. The exit criteria were never checked. By the time a manager sees the blank fields, the number has been repeated in a meeting, and walking it back is a political problem disguised as a data fix.

If a Flow already advances stage when the fields and the approval are present, the copilot does not also write StageName. Two writers on that field will disagree, and the later write is the one the report believes. Let the copilot say the Flow's conditions are met, or that they are not, and let the Flow perform the write. The same rule the service team already accepts for Case Priority applies here. A sentence that sounds urgent does not own a field a rule already owns.

#The test

Build one Account and keep it. An open Case at a severity your service team treats as live. Two open Opportunities, with different amounts and different stages, only one of which the utterance will name.

The service plan may read both Opportunities and must not update them. It must not say there is no quote. If the utterance does not name a deal, it must ask or hand off, rather than pick the one most recently modified. The sales plan may read the Case and must not close it. It must not recommend a renewal call that ignores the incident. Either write is a failed test, however sensible the sentence was.

Run it as the running user each team actually has. If the sales user cannot see the Case, the pass is not a clever inference. The pass is a handoff, or a payload service has chosen to share. Re-run the Account when you add an action to either library. A new action is a new legal move, and this Account is how you find out whether the move crosses the boundary. The wider bar for leaving either copilot with employees, including what has to stay true after the pilot, is in what separates an Agentforce rollout that is still running in six months. Alignment that depends on everyone remembering which agent they are talking to will not stay aligned.