It usually surfaces as a bug that was already fixed. A validation rule is back to its old wording. A trigger has lost the condition someone added last week. A flow is missing the branch that went live on Monday. Nobody deleted anything on purpose, and the deployment log shows nothing but green ticks.
What happened is simple: two people changed the same component, and the second deployment replaced the first.
This post explains why Salesforce lets that happen, the situations where it bites, the habits that prevent most of it, and how team conflict detection in orgadmin.ai catches the overlap while the work is still in progress, before anyone deploys.
Why Salesforce lets one deployment undo another
When you deploy an Apex class, a Lightning web component or a flow, the Metadata API does not merge your version with what is in the org. It replaces the component with the copy you sent. If that copy started from an older version, everything changed in the org since then is gone.
There is no lock that says "Priya is editing this class", and no warning that the copy in the org changed since you took yours. The deployment succeeds, because from Salesforce's point of view nothing went wrong. The last deploy wins.
Developers who use the Salesforce CLI with source tracking get some protection: it can report a conflict when the org's copy has changed since your last retrieve. But that covers one org and one person's local project. It knows nothing about the colleague doing the same work in a different sandbox.
The three ways teams overwrite each other
1. Two people in the same sandbox
The most direct case. A shared dev or UAT sandbox, two people, one component. Daniel retrieves AccountTriggerHandler on Monday and starts on territory changes. Tom retrieves it on Tuesday for a partner sync fix and deploys on Wednesday. Daniel deploys on Thursday, from his Monday copy. Tom's fix disappears, and Tom will not find out until his test fails or a user complains.
2. Different sandboxes, same component
More common, and harder to see. Jess changes a flow in her developer sandbox while Priya changes the same flow in hers. Neither can see the other's work, because each sandbox is its own copy. Both changes pass testing. Both get promoted to UAT, then production. Whichever is promoted second wins, and the other change quietly vanishes.
Git-based release processes catch this when the two branches are merged, but only for teams that put every change through source control, and only once both people have finished the work. Many Salesforce teams build directly in sandboxes and promote with change sets or org-to-org deployments. For them, nothing catches it at all.
3. Building on an old copy of production
Someone makes a hotfix in production on Tuesday. On Friday, a developer deploys a sandbox copy of that component that was refreshed a month ago. The hotfix is reverted. Nobody in the team touched the same component at the same time; the developer's copy was simply older than production.
Habits that prevent most overwrites
None of these need new tools. They need discipline, which is the hard part.
- Say what you are working on. A shared list or a Slack channel where people claim components ("I'm in AccountTriggerHandler until Thursday") prevents the obvious collisions. It only works if everyone keeps it up to date.
- Keep work short-lived. A change that sits in a sandbox for six weeks is much more likely to collide than one that ships in three days.
- Refresh before you deploy. Retrieve the target org's current copy and compare it with yours. If the org has changed since you started, merge those changes into your version before deploying.
- Compare before you deploy. An org-to-org comparison shows exactly which components differ between your sandbox and the target, and a side-by-side diff shows what each change contains. A change you did not expect in the target is the warning sign.
- Validate first. A check-only validation proves the package deploys and its tests pass, without changing the org. It will not detect an overwrite, but it gives you a moment to review what you are about to send. See Salesforce quick deploy for the validate-then-deploy routine.
- Treat production changes as part of the release. If someone has to change production directly, tell the team and bring the change back into the sandboxes, so the next deployment does not undo it.
The common weakness is that every one of these depends on someone remembering. Overwrites happen on busy days, which is exactly when people forget.
How orgadmin.ai team conflicts catch it for you
orgadmin.ai now includes team conflict detection for company workspaces. It looks at what everyone in the workspace is changing in the Development Studio, across every member's sandboxes, and warns before one person's work overwrites another's.
Overlaps are matched across the whole team
Each Apex class, Lightning web component and metadata file (such as a flow) that someone is changing is matched by its type and name across the whole workspace, not one org at a time. So Jess's flow in her sandbox and Priya's copy in hers are recognised as the same flow.
When you open a project, any component a teammate is also changing shows a small badge in the file tree. Hover over it to see who, in which org, in which project and when they last edited it. The org decides how serious it is:
- Same org: whichever of you deploys second overwrites the other. The deploy dialog lists these first and says so in as many words.
- Different sandboxes: you will clash when you both promote. It is worth a conversation now, while it is cheap.
Deploys wait until you have checked
If anything you are about to deploy overlaps a teammate's work in progress, the deploy dialog lists it, for example "Tom Walsh is changing it in Northwind UAT too". Deploy stays disabled until you tick "I've checked with them, and deploying won't undo their work."
It does not block you, because sometimes the overlap is planned. It makes sure the decision is made on purpose. The check runs on the server as well as in the dialog, and each acknowledgement is written to the audit log. Validations go through without the tick, because a validation saves nothing and cannot overwrite anyone.
The same warning appears on org-to-org comparison deployments, which is how most teams promote from sandbox to UAT. There it also lists teammates' recent deployments of the same components into the target org, which is the work your deployment would replace.
Finished work stops warning anyone
The hard part of a tool like this is old work. Projects are rarely tidied up, so a project from three months ago that has long since gone live would otherwise warn everyone forever. Each piece of work therefore gets a production status:
- Live in production: production already has the change, so it stops counting straight away.
- Built on an older version: production has changed the component since the work started. Its owner sees a warning to refresh before deploying, so they do not undo someone else's change. This catches the third case above.
- Older work: nobody has edited it for 30 days. It is listed, but does not warn.
You can check your own projects against production on demand, using your own production login. Projects whose work is all live get a prompt to archive them, so your project list stays focused on work in progress.
A conflicts page for team leads
Owners and admins get a Team conflicts page: every component that more than one person is changing, grouped by component, with "Same org" and "Across sandboxes" marked. It shows who, which project, which org, the status and when it was last edited. Before release day, a lead can see which components need a conversation.
What it does not do
Teammates see the component's name, your name, your project, the org and when you last edited it. They never see your code.
It also does not see changes made straight in Setup as overlaps, because it tracks Development Studio projects and deployments run through orgadmin.ai. Production changes still show up, though: once the production copy is refreshed, work built on an older version is flagged.
The short version
Salesforce will always let the last deployment win. You cannot change that, but you can make sure nobody wins by accident. Talk about what you are changing, keep work short, refresh and compare before you deploy, and let a tool watch for the overlaps people forget.
If your team already shares sandboxes and a release calendar, team conflict detection is included in every company workspace. Nothing to configure: it starts working as soon as two people touch the same component.