Salesforce merge conflicts happen when two developers or admins change the same metadata component in different branches or sandboxes, and the platform's XML-based structure makes those collisions far more common than in typical code repositories. A profile file touching forty objects, a flow with a dozen decision elements, a permission set bundling field-level security across three clouds — any one of these can turn a routine pull request into a two-hour untangling session. The real cost isn't the conflict itself. It's the deployment freeze that follows while two teams argue over whose version of a picklist value set should win.
Most engineering leaders assume merge conflicts are a version control problem. On Salesforce, they're an architecture problem wearing a git costume. Fix the metadata sprawl and the conflicts mostly stop finding you.
Why Salesforce Metadata Invites More Conflicts Than Regular Code
A typical Apex class conflict is easy to spot. Two people edited the same method, git flags the overlapping lines, someone picks a version, done in five minutes. Salesforce metadata doesn't play by those rules. A single profile XML file can represent field-level security for hundreds of fields across dozens of objects, so two admins working on completely unrelated features can still collide inside the same file just by saving changes through the setup UI.
Flows make this worse. Every time someone opens Flow Builder and clicks save, the entire flow definition gets rewritten, including elements nobody touched. That's not a bug, it's how the metadata API serializes the component. So a conflict between "add one validation step" and "rename a variable" often looks like a conflict across the whole file, because technically it is one.
Add in the fact that admins frequently make changes directly in a shared sandbox, outside any branch at all, and you get metadata drift layered on top of merge conflicts. By the time someone pulls that sandbox's state into source control, it's not clear which changes were intentional and which were leftover experiments nobody cleaned up.
The Usual Suspects: Profiles, Flows, and Layouts
Not every metadata type carries equal risk. Some components are structured narrowly enough that conflicts stay contained. Others are broad by design and collide constantly.
| Metadata Type | Why It Conflicts Often | Typical Fallout |
|---|---|---|
| Profiles | One file covers field, object, and app permissions across the entire org | Silent permission overwrites, users losing access after a deploy |
| Flows | Full definition rewritten on every save, even unrelated edits | Whole-flow conflicts that look bigger than the actual change |
| Page Layouts | Shared across multiple record types and profiles | One team's field addition undoes another team's field removal |
| Permission Sets | Increasingly used to replace profiles but still bundled broadly | Harder to review in pull requests, easy to approve blindly |
Notice the pattern. It's not that these components are edited more often than Apex classes. It's that each edit touches a wider surface area, so the odds of two people landing on the same file rise sharply as team size grows.
Where Conflicts Actually Surface and Why Timing Hurts
A conflict caught during a pull request costs a reviewer ten minutes. A conflict caught during UAT costs a sprint. The gap between those two outcomes is entirely about when the collision gets detected, not whether it happens.
Teams running proper source-driven development see conflicts at the git level, before anything touches a shared org. That's the cheap version. Teams still relying on change sets or manual retrieval from sandboxes tend to discover conflicts only after a deployment partially succeeds, leaving the target org in a mixed state where some components updated and others didn't.
The worst version happens when two release trains both deploy to the same full or partial copy sandbox for testing, and neither team realizes the other overwrote their flow version until QA reports a broken process two days later. At that point nobody trusts the sandbox, and someone has to reconstruct which change is actually correct from memory or Slack history. This is exactly the scenario a validation step before deployment is meant to catch, comparing incoming metadata against target org state and flagging overlaps before they land.
Branching and Ownership Models That Cut Collisions
Long-lived feature branches are the single biggest driver of Salesforce merge conflicts. The longer a branch exists apart from the main line, the more metadata drifts between them, and the bigger the eventual reconciliation. Teams that keep branches alive for three or four weeks while a feature gets built are almost guaranteeing a painful merge on the way back in.
Trunk-based development, or something close to it, cuts this dramatically. Short-lived branches, frequent small merges, and feature flags to hide incomplete work in production reduce the window where two people can independently touch the same component without knowing it. This isn't a new idea in software engineering generally, but Salesforce teams adopt it far less often than they should, partly because clicks-based development doesn't naturally fit a branching workflow at all.
Component ownership helps just as much. Assigning specific objects, flows, or automation domains to specific teams means fewer people are ever touching the same file in the first place. It sounds obvious, but most orgs I've reviewed have no documented ownership map at all, just a shared understanding that gets fuzzier every time someone leaves the team.
- Keep branches alive for days, not weeks
- Assign metadata ownership by object or business domain, not by sprint
- Replace broad profiles with permission set groups scoped to a role
- Require a diff review on flows before merge, not just an approval click
Resolving a Conflict Without Guessing
When a conflict does surface, the instinct is to pick whichever version looks more complete and move on. That's how regressions get shipped. A flow that compiles fine can still be missing a decision branch someone else added last week, and nothing in the deployment process will flag that as an error, only as a behavior change nobody notices until a customer hits it.
A better process treats every metadata conflict as a three-way comparison: the common ancestor, and both diverging versions. Tools built for Salesforce metadata, rather than generic text diffing, make this readable instead of a wall of XML. DeployEzee's validation step runs exactly this comparison against the target org before anything deploys, so a conflict gets flagged as a decision to make rather than a surprise to debug after the fact.
Once the conflict is resolved on paper, it still needs to run through actual test coverage and, ideally, a sandbox seeded with data that resembles production volume. A merged flow that passes review can still fail under real record counts if a loop or SOQL query behaves differently at scale, which is one more reason validation sandboxes need production-like data rather than a handful of test records.
Building an Org Structure That Prevents the Next One
The teams with the fewest merge conflicts aren't the ones with the best conflict-resolution process. They're the ones who structured their org so fewer conflicts are possible in the first place. That means smaller, more granular permission sets instead of monolithic profiles. It means splitting large flows into subflows with clear boundaries, so two people working on different logic paths aren't forced into the same file. It means unlocked packages or clearly scoped metadata folders that map to actual team ownership, not an org-wide dumping ground.
None of this happens by accident, and none of it happens fast. It takes a deliberate decision to refactor permission architecture and flow design with conflict surface area as an explicit goal, not just a maintainability nice-to-have. Teams that treat this as optional tend to keep paying the merge-conflict tax release after release, and the tax compounds as headcount grows.
Growth is really the forcing function here. A five-person admin team can get away with sloppy metadata boundaries because collisions are rare by sheer coincidence. A twenty-person team working across four release trains does not get that luxury, and the cost of ignoring ownership design shows up as slipped release dates rather than a line item anyone budgeted for.
Frequently Asked Questions
What causes most Salesforce merge conflicts?
Most conflicts come from broad metadata files like profiles and flows, where a single save rewrites the entire component even if only one small piece changed. Two people editing unrelated parts of the same profile or flow will still collide because the file itself, not just the specific setting, gets flagged as changed. Long-lived feature branches make this worse by widening the gap between diverging versions.
Can Salesforce merge conflicts be avoided entirely?
Not entirely, but they can be reduced sharply through short-lived branches, clear component ownership by team or domain, and replacing large profiles with scoped permission set groups. Teams that merge small changes frequently see far fewer collisions than teams that let branches run for weeks. The goal is smaller conflicts caught early rather than zero conflicts, which usually isn't realistic on a growing org.
Why do flow conflicts seem bigger than the actual change?
Flow Builder rewrites the full flow definition every time someone saves, even if they only touched one element. That means a conflict between two small edits often looks like a conflict across the entire flow file. Reviewing the actual rendered logic, not just the raw XML diff, is the only reliable way to tell how big the real change is.
How do merge conflicts differ from metadata drift?
A merge conflict happens when two branches change the same component before either is deployed, and version control flags the overlap directly. Metadata drift happens when a sandbox or production org changes outside of version control entirely, so there's no branch to compare against, just an org that no longer matches what's in the repository. Drift is often harder to catch because nothing automatically flags it the way a git conflict does.
What's the safest way to resolve a Salesforce metadata conflict?
Compare both diverging versions against their common ancestor rather than just picking the version that looks more complete. Run the resolved metadata through full test coverage and, where possible, validate it in a sandbox that reflects production-like data volume before deploying further. Skipping that validation step is how a technically correct merge still ships a behavior regression nobody caught in review.