# Best practices for managing automated workflows in Agentforce A workflow that already has a right answer belongs in Flow or Apex. The agent decides which action to call, when it has enough to stop, and when the next move belongs to a person. **Published:** 2025-10-13 **Canonical:** https://synconai.com/best-practices-automated-workflows-agentforce **Author:** SynconAI Architecture Team ## In short On a workflow that already has a right answer, an agent is the wrong owner. Flow or Apex performs the step. The Atlas Reasoning Engine breaks a request into smaller tasks and proposes a plan. That plan should call a tested action, then stop. A second write on a field the Flow already owns is a defect, even when the sentence sounded urgent. Consequential actions hand off to a person. ## Sources - **Agentforce: How does Agentforce work?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > It starts with the Atlas Reasoning Engine, which breaks down the initial prompt into smaller tasks, evaluating at each step and proposing a plan for how to proceed until the complete answer or action is achieved. - **Agentforce: How do you build AI agents?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > Businesses can build agents with Agent Builder using existing Salesforce Platform tools to create standard and custom subagents and actions. ## What to take away - If the same input must always produce the same output, the step belongs in Flow or Apex, and the agent may only start it. - The agent chooses which action to call and stops when a record Id is back, not when the reply sounds finished. - Build that action in Agent Builder, then test the plan. A fluent sentence can hide a skipped branch. - A change to money, access, or legal status is a queue handoff with the facts attached, not a model guess. ## The guide A customer writes that the order has not shipped and that it is urgent. The agent sets Case Priority to High. A record-triggered Flow then sets Priority from the account tier, which is Standard. The transcript says urgent. The list view sorts Standard. The person who opens the Case spends the first minute reconciling a priority the customer can already quote from the chat. Two writers touched one field. The Flow was the owner. The agent was the later writer, and the later write is the one the board believes until the Flow runs again and quietly puts it back. On a workflow that already has a right answer, an agent is the wrong owner. Flow or Apex should perform the step. The agent decides which action to call, when it has enough to stop, and when the next move belongs to a person. ## The plan is for a sentence, not for a rule Salesforce describes the Atlas Reasoning Engine as the piece that breaks the initial prompt into smaller tasks, evaluates each step, and proposes a plan until an answer or an action is reached. That is useful when the request is a sentence and the path is not obvious. "The shipment never arrived and I need this for a site visit tomorrow" might be a status question, a complaint, or a change of address. A person can hear which one it is. A menu often cannot. The plan is allowed to make that classification and then call one action. It is a poor tool for a rule the organisation has already written down. Assignment from a queue matrix, an entitlement milestone, a discount band, a tax calculation, an approval chain: these have the same output every time the same input arrives. If a formula, a decision element, or a tested Apex method can express the rule, that object is the owner. Asking the model to apply the rule again does not add care. It adds a second outcome that will sometimes differ, and the difference will look like judgement. The practical test is boring and reliable. Take the input and ask whether a new starter, given the written rule, would be wrong to produce a different output. If they would be wrong, the step is deterministic, and it does not belong in the plan. If two careful people could disagree until they had read the sentence, the step is interpretation, and that is the agent's work. ::: warn A fluent reply is not evidence the right action ran. Read the plan. If Priority was written by the agent and a Flow also writes Priority, the test has already failed, however polite the paragraph was. ::: ## What to put in the agent Put interpretation in the agent. A person writes a sentence. The agent works out whether that sentence is a status question, a change, or a complaint, then calls one action from the library. Agent Builder is where that library lives. Salesforce describes it as standard and custom subagents and actions, built with the platform tools you already run. Give a subagent one job. Give an action one effect: read a Case, start a Flow, create a Task, or place the record on a queue. An action with two effects is two actions wearing one name, and the plan cannot stop halfway through a name. Write the instructions as stop rules. Name the objects. Name the action for each kind of request. Name the finish. If Case Status is already Closed, do not reopen the record. Return the case number and stop. If the action returns an Id and the required fields are filled, stop. If a required field is blank and only the person can supply it, ask once, and if they do not supply it, hand off. "Be helpful" is not a stop rule. It is how a plan calls the same action twice, and a second create is how the organisation grows a duplicate Case that nobody requested. The instruction should be shorter than the policy it points at. If you paste the refund rules into the instruction, you now have two copies, and the one in the instruction will be the one nobody updates. Point at the Flow that already encodes the rule, or at the article a person maintains. The instruction says which action to call, and what to do when that action returns nothing. How those instructions should be written, including the refusals, is the subject of [writing the prompt that actually persists](/prompts-einstein-and-agentforce). ## What to leave in Flow or Apex Leave deterministic work in Flow or Apex. Assignment, entitlement milestones, approval chains, discount bands, tax, and any field update that must match every time are steps, not plans. The wider decision of which of those two objects should own a given rule is set out in [Flow or Apex: write the decision down](/insights/flow-or-apex-write-the-decision-down). This page only needs the boundary with the agent: whichever object owns the rule, the agent does not become a third owner. The agent may start the Flow. It may pass the inputs the Flow declares. It may not reimplement the Flow in instructions, and it may not write the fields the Flow writes. Two writers on one field is a defect even when the second writer is trying to be attentive. When a record-triggered Flow sets Case Priority from the account tier, the agent does not also set Priority because the email sounded urgent. The Flow has already run, or it will run when the record saves. A second write looks like judgement and is only noise. The customer's words still matter. They belong in the description, or in a note, where a person can read them. They do not belong in a field that a formula has already decided. Apex is the same kind of owner when the method is already under test. The agent calls it. The agent does not invent an Opportunity line the class never created, and it does not finish a calculation the method returned as a partial. If the method needs three inputs and the sentence only contained two, the plan stops and asks, or it hands off. It does not guess the third input so the call will succeed. A guessed input is how a tested method produces an untested result. There is a shape of work that looks deterministic and is not. "Update the Case" is not a rule. Which field, from which source, under which condition, is the rule. If you cannot write that sentence, you do not yet have something to put in Flow, and you also do not yet have something to hand to an agent. Building the agent first, and hoping the instruction will settle the rule, is how the instruction becomes a shadow Flow that only fails on the records you did not demo. ## One owner per step The argument becomes easier when each step has one owner written down. The agent column is allowed to say "starts it" or "reads it". It is not allowed to say "also writes it". | Step | Owner | What the agent may do | What goes wrong if the agent also writes | | --- | --- | --- | --- | | Priority from account tier | Record-triggered Flow | Record the customer's words | The list view and the transcript disagree | | Queue assignment | Flow | Start the Flow, or leave it | Work sits with the agent and the queue | | Discount band | Flow or Apex | Collect quantity and the product | A figure the policy never allowed | | Tax | Apex | Pass the inputs the method declares | A second total beside the official one | | Refund | A person, or a Flow that encodes the policy | Collect amount, reason, and the record Id, then hand off | Money moves because a sentence was confident | | Closed Case status | The record | Read the number and stop | The Case reopens without a new reason | Read the last column before you add an action. If you can already picture the incident, the action is too wide, or it overlaps an owner you already have. A custom copilot for an employee has the same boundary, which is why [a custom copilot is a short library, not the whole org](/build-custom-copilots-agentforce-builder). ## When the agent must stop Stopping is a record and a handoff, not a softer line in the instructions. Stop when the action returns a record Id and the required fields are filled. Stop when the person asks for a person. Stop when the next step would change money, access, or a legal status. Stop when you have asked for the missing fact once and it has not arrived. A second, rephrased question is usually the plan trying to be helpful past the point where it has information. Agents may act inside guardrails. Consequential actions hand off. Salesforce's line is that agents escalate when the issue is beyond their scope. Make that a concrete Case update: the status stays open, the owner becomes a queue, and a short note records what was read and what was refused. A refund, a contract edit, or a permission change waits for a person, or for a Flow that already encodes the policy. The note is part of the stop. "Please assist" is not a handoff, because the next person has to start the identification again, and the customer hears their own story for the second time. Write the out-of-scope list as behaviour the plan can see on every turn, not as a slide. Any mention of a regulator. Any request to change who can log in. Any amount that would leave the organisation. The list will be shorter than the team's anxieties, and that is fine. A short list that is tested beats a long list that lives in a document the instruction never points at. ::: note The finish condition names a record, not a mood. "The customer seems satisfied" will keep the plan talking. "The Case Id is back and Status is set" will stop it. Satisfaction is something a person can judge later, from the reopen, not something the plan should infer in the moment. ::: ## How this fails Three failures show up in the first real week, and each one is visible in the plan if someone reads it. The agent skips a branch the Flow always took. The Flow checked entitlement before it created the follow-up Task. The instruction summarised the Flow as "create a Task when they ask for a callback" and dropped the check. The Task exists. The entitlement does not. The failure looks like a helpful callback until the milestone report is wrong. Or the plan calls create-case twice, because nothing told it to stop when the Id came back. The organisation now has a duplicate. Both Cases sound reasonable. The customer replies to one of them. The other sits open and ages into a different person's queue. Or the agent updates a field and a later Flow overwrites it, so the transcript and the record disagree. The customer quotes the chat. The person on the phone quotes the record. Both are quoting something your system said. The Flow was right. The agent was a second writer. Test the plan the agent proposes, not only the final sentence. Read which action ran and which inputs were passed. A fluent reply that started the wrong Flow is a failed test. A short reply that started the right Flow and stopped is a pass. Keep a small set of sentences that must always take the same path: a closed Case, a refund request, a priority complaint on an account whose tier is already known. If a deterministic case changes path after an instruction edit, the edit has started to reimplement a rule. Move that step back to Flow or Apex. ## Instruction drift The instruction starts short and grows every time a case surprises someone. A sentence is added for the partner channel. Another for a particular product. Another for the week finance changed the discount bands. After a month the instruction is a second specification of rules that already live in Flow, and it is the copy nobody can regression-test. Watch for a specific smell. A deterministic input, one you used in the original test, takes a different path after an edit that was meant to cover a different topic. The edit has coupled two jobs. Split them. The new exception is either a branch in the Flow, where it can be named and tested, or it is a separate subagent with its own stop. It is not a paragraph appended to a subagent that used to have one job. Then re-run the small set. Do not re-run the demo sentence that happened to sound good in the meeting. Re-run the closed Case, the refund, and the priority complaint. If those three still take the original path, the edit was local. If they do not, revert the edit before you discuss the tone of the reply. The readiness work around this boundary, including what has to be true before an agent is left with customers, is set out in [what separates an Agentforce rollout that is still running in six months](/insights/agentforce-implementation-best-practices). The piece that fails first is not the wording. It is an action library that overlaps automation the org already trusted. ## Questions ### Should Agentforce replace our existing Flows? No. A Flow that already produces the same output for the same input should stay the owner of that step. The agent can start the Flow and pass the inputs the Flow declares. It should not contain a second copy of the decision in its instructions. Replacing a tested Flow with a plan makes the outcome vary, and it makes the failure harder to see, because the reply can still sound right when a branch was skipped. ### What work is a good fit for the agent? Work where the input is a sentence and the right action is not obvious until someone reads it. The agent classifies the request and calls one action from the library you built in Agent Builder. Status versus complaint versus a change of address is that kind of read. Once the action is obvious from fields alone, that step belongs in Flow or Apex. If a new starter with the written rule would be wrong to produce a different output, the step is not the agent's. ### How do we stop an agent from looping on the same action? Write a finish condition that names a record, not a mood. Stop when the action returns an Id, or when a required field is still blank and a person must supply it. Ask for that field once. "Be helpful" will call the action again, and a second call is how duplicate Cases appear. If the plan searches again after the Id is known, treat that trace as a failed test and tighten the stop before you edit the tone of the reply. ### Can the agent update Case Priority if the customer sounds urgent? Only if no automation already owns Priority. If a record-triggered Flow sets Priority from account tier or entitlement, a second write from the agent fights that Flow, and the later write is what the list view believes until the Flow runs again. Let the agent record the customer's words on the Case. Let the Flow set the field. Urgency in a sentence is a fact about the conversation. It is not, by itself, the rule your queue was built on. ### Who approves a refund or a permission change? A person, or a Flow that encodes the policy with no room for a guess. The agent may collect the amount, the reason, and the record Id, and it should then hand the Case to a queue with those three written down. Consequential actions stay outside the plan even when the reply sounds certain. Salesforce's line is that agents escalate when the issue is beyond their scope. A confident paragraph that moves money is the case that line was written for. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).