How to Ensure AI Coding Agents Follow Current Flow Best Practices
Last reviewed: September 18, 2026
AI coding agents sometimes build Salesforce Flows from outdated patterns. Their training data has a cutoff date, and older solutions appear far more often in public material than newer Flow features. The result can work correctly while still looking several releases out of date.
A newer model alone won't solve this. Documented guidance on current Flow elements and clear direction on which existing Flows are suitable templates make the outcome more dependable.
Why older patterns dominate
A model learns from data that may already be months old when it becomes available. Salesforce, meanwhile, publishes three releases a year. New Flow features can therefore be missing even from a recently released model.
What matters most is which sources are available online. Older tutorials, forum answers and blog posts keep feeding into the answers, even long after Salesforce has published a new Flow element. A ten-year-old Flow feature therefore has far more examples than one from the latest release, so a model will often fall back on the better-documented option.
An outdated answer can still sound convincing. The model has seen plenty of examples for that design, even though Salesforce now offers a better option.
One way around this is to tell the agent to use only current Flow elements and to research them on the web first. That repeats the same work for every task, though. Depending on the model and its search integration, current sources may be given priority. But the research can still land on older tutorials that already shape the training data. As search results keep shifting, no commonly reviewed set of guidance ever emerges.
Examples of Flow designs built from old material
Without clear guidance, an agent often reaches for the same designs. One of the most consequential is creating or updating records inside a loop. The Flow may work with a few test records, but it quickly hits Governor Limits at a larger data volume.
Other outdated designs are less obvious. A Flow might update the triggering record after save, even though a before-save update could set the same field without a second save. Or it may build a filtered collection inside a loop using a decision element, even though the newer Collection Filter element does the same in one step.
The remaining examples follow the same pattern. Although the Salesforce platform now provides a new element, the agent keeps assembling the solution from loops, decisions and assignments.
| What you need | What comes back without current Flow guidance | What the platform now offers |
|---|---|---|
| Filter a collection | A loop and a decision populate a second collection | Collection Filter element |
| Reshape or summarise fields | Counters and running values inside a loop | Transform element |
| Choices drawn from records | Get Records, a loop, and a hand-built choice | Record Choice Set |
| A screen that responds to input | A second screen refreshes the values | Reactive screen components |
| Callouts, email, follow-up work | Everything synchronous in the main path | Asynchronous path |
| Field update on the triggering record | An update applied after save | Before-save update |
| Trigger timing on a specific date | A nightly batch job | Scheduled path |
Each design can work on its own. Once the finished Flow is in the org, however, it becomes a potential template. The next agent reads it as an existing pattern and copies the same structure.
Flow guidance belongs in the project
A detailed prompt before every task helps immediately, but it lasts for only one session. It disappears at the next start, is difficult to reproduce consistently across a team, and becomes harder to maintain with every addition.
One option is to keep versioned instructions and references in the project. The implementation depends on the tool and the team's workflow. Claude Code can read CLAUDE.md, rules under .claude/rules/, and skills from .claude/skills/. Repeatable checks can also run through hooks. Codex reads AGENTS.md, while Cursor uses rules under .cursor/rules/. Teams can combine these mechanisms to suit the project.
When the instructions, references, and checks live in the repository, they go through the same review as any other change. They can be updated deliberately with every Salesforce release, and the team can see which knowledge and checks shaped the agent's work.
One central rule should require the simplest element that meets the requirement. Being new isn't a reason on its own. Without that guidance, the agent may answer every requirement with the latest feature, producing something as difficult to maintain as the loop chain it replaced.
The file can also record the org's conventions, such as a fixed scheme for API names, descriptive element names, and a description for every element. That stays reliable only once a deterministic check verifies them against the org's metadata. This helps both the person who later opens the Flow in Flow Builder and the next agent that reads the org.
Verify against the target org
When a feature's availability changes the design, the agent must check the target org's API version and the official release notes instead of relying on training data.
For features that Salesforce no longer develops, a short context rule can be the first step. Salesforce, for example, stopped accepting new workflow rules and new Process Builder processes a while ago, and support for both ended on 31 December 2025. Existing processes keep running and can still be activated, deactivated and edited, but Salesforce no longer fixes bugs in them.
An instruction to the AI agent such as "no new workflow rules, no new Process Builder processes" gives it a clear boundary, but it can't guarantee compliance on its own. That requires a harness combining context, hooks, and technical checks (the control layer that surrounds an AI model). A Salesforce AI Engineer can, for example, take responsibility for building and maintaining the harness. A script can compare the generated metadata with the target org's API version and enforce constraints that context alone can't convey reliably.
For this check, Salesforce CLI connects to an authorised target org. A check-only deployment submits the Flow metadata to Metadata API without saving changes to the org. Salesforce then reports invalid field references, missing elements, or an unsupported API version. Existing Flow tests can run in the same pass. A regular deployment performs the same validation before Salesforce applies the changes. Without org access, the agent can provide a detailed build specification for Flow Builder, but not a result verified by Salesforce.
Your Salesforce org also shapes how the AI agent builds
Guidance on current Flow elements isn't enough because an AI coding agent also reads the org's metadata before it writes anything.
What it finds there shapes the result. If three fields hold the same information, the agent has to guess which one is maintained. Broad permissions also leave it unclear which parts of the org the agent is allowed to change.
Existing Flows are especially influential. When an agent uses one as a template, it also inherits the way that Flow was built. If the org still contains automations from before the Collection Filter element, its metadata reinforces the now-outdated design found in the training material. The knowledge file should therefore identify which Flows are suitable templates, which are awaiting migration, and when a Flow should be rebuilt.
Trigger order matters too. Salesforce stores it in the triggerOrder field of each record-triggered Flow. An agent can read that value from retrieved Flow metadata and should preserve the existing order instead of inventing a new one. Whether to change it should remain a decision for the Salesforce team.
A new colleague develops the same context during onboarding. The agent reconstructs it from metadata on every run and knows nothing about decisions the team hasn't documented.
Before building the first agent-assisted Flow, you should therefore analyse the current state of the Salesforce org and prepare it deliberately for the use of AI. That means an unambiguous data model, known overlaps between automations, and deliberately set access boundaries. The team can then decide for itself which structures and Flows the agent may use as a dependable foundation.
What the Salesforce team should decide for itself
Decide in advance which choices your team will make, even when AI coding agents know the current Flow elements and org conventions. When building screen flows, for example, this is especially relevant. The agent can account for the structure and existing metadata, but it doesn't know how people use the screen during their working day. Only those users can confirm whether the field order follows a phone conversation or whether a label still makes sense in its embedded context.
The team should also define naming standards, sensitive objects, and ownership. Using a beta feature or an additional licence is a clear product decision too. An AI agent's first results should therefore be assessed like a new colleague's work, every time and against a consistent checklist.
Where to start
If you want AI coding agents to build Flows, it's best to start with the following two steps. First, record current Flow elements and your org conventions in versioned project instructions. Then establish which structures and existing Flows in the org provide a dependable foundation. A Platform Assessment can also help you analyse the current state of your Salesforce org and point out recommended improvements before you first put AI agents to work.