Migrate Org-Wide Defaults and Sharing Rules Between Salesforce Orgs
Can you move Org-Wide Defaults and Sharing Rules from one Salesforce org to another? Yes — OWD is a value on the object's metadata and sharing rules are a per-object component, so both are deployable; the platform's own tooling just makes it awkward. It's one of the oldest questions on the platform — the most-viewed sharing question on Salesforce StackExchange asks exactly this — and the usual answer is a shrug. Change sets carry OWD invisibly inside the object, treat each object's sharing rules as an all-or-nothing blob, and give no warning when a rule points at a group the target doesn't have.
Where OWD and sharing rules live in metadata
- Org-Wide Default is the object's sharing model: a
<sharingModel>value on the CustomObject (Private,Read,ReadWrite,ControlledByParent, …). It rides inside the object's metadata, which is why it's easy to miss. - Sharing Rules are a per-object
SharingRulescomponent — criteria-based, owner-based, guest, and territory rules together. You deploy the wholeObject.sharingRulesfile; a single rule can't be cherry-picked through metadata.
mtdt.io deploys both, in one run
With mtdt.io both are first-class, selectable metadata. Pick the object (it carries the OWD) and its Sharing Rules, and they deploy together org→org in a single run — no connected-org plumbing, no change set:
mtdt also shows the OWD change as a first-class diff. Open the object's comparison in Table View and the sharing-model flip shows as a named row:
It recommends the group or role a rule shares to
A sharing rule shares to a group or role, and that's a hard deploy dependency: ship a rule whose group doesn't exist on the target and Salesforce rejects it with no Group named X found. Salesforce's own dependency graph doesn't model that link, so a tool leaning on it gives no warning. mtdt.io fills the gap — its Impact Analysis reads the rule's sharedTo and recommends the group or role, flagged New when the target is missing it:
Include it in the same deploy and the rule lands cleanly.
The two Salesforce limits mtdt warns you about
Some constraints come from Salesforce itself, and mtdt.io surfaces them up front:
- An owner-based rule can't change alongside the OWD in one deploy. Salesforce won't let you flip an object's sharing model and add a new owner-based rule in the same deployment (criteria-based and guest rules are fine). mtdt warns before you run it and tells you to split the two:
- OWD changes apply asynchronously. When a deploy changes the sharing model, Salesforce recalculates record access in the background — so "deploy succeeded" doesn't mean the new access is live yet. mtdt notes this on the successful deploy (see the first screenshot), so you know to give the recalculation a moment before checking.
FAQ
Can you deploy Org-Wide Defaults with the Metadata API?
Yes. OWD is the <sharingModel> value on the object's CustomObject metadata, so it deploys as part of the object rather than as its own component. That's also why it's easy to miss — mtdt.io shows the sharing-model change as a named row in Table View so it isn't buried inside the rest of the object's diff.
Can you deploy a single sharing rule without the rest of the object's rules?
No — Salesforce's SharingRules component is per-object, and you deploy the whole Object.sharingRules file as a unit; individual rules can't be cherry-picked through metadata. mtdt.io deploys that same per-object file, so the granularity limit is Salesforce's, not the tool's.
Why does a sharing rule deploy fail with "no Group named X found"?
Because a sharing rule shares to a group or role, and Salesforce's own dependency graph doesn't track that link — if the group doesn't exist on the target, the deploy is rejected. mtdt.io's Impact Analysis reads the rule's sharedTo value and recommends the group or role automatically, flagging it New when the target is missing it.
Why doesn't record access update right after an OWD deploy succeeds? Because Salesforce recalculates record-level access asynchronously after a sharing-model change — a successful deploy just means the metadata change was accepted, not that the recalculation has finished. mtdt.io notes this on the deploy result so you know to give it a moment before checking access.
Can you change an object's OWD and add an owner-based sharing rule in the same deploy? No — Salesforce blocks flipping an object's sharing model and adding a new owner-based rule in one deployment, though criteria-based and guest rules are fine alongside an OWD change. mtdt.io warns about this before you run the deploy and tells you to split the two.
Can you deploy more than one sharing rule at once, or does the second one fail?
You can. An older error — the second rule failing with sharing operation already in progress — used to bite when two rules shipped in one deployment, but on today's Metadata API multiple rules on the same object deploy together fine (mtdt.io deploys the object's whole rules file in a single run). The error survives only for deploys that force two sharing recalculations to collide — most concretely an OWD change plus a new owner-based rule together, which mtdt.io flags before you run it. The fix there is to split the deploy so each recalculation finishes first. For large sharing migrations, Salesforce's Defer Sharing Calculations (a Setup feature Salesforce Support enables) lets you suspend recalculation during the deploy and resume it at a quieter time.
Migrate sharing the way you migrate everything else
Let mtdt.io move your Org-Wide Defaults and sharing rules org→org in one run — with the OWD flip shown as a real diff, the group a rule needs recommended up front, and Salesforce's own sharing limits flagged before they bite.
Log in to mtdt.io and migrate your sharing model.
Related: The Best Way to Deploy Profiles · Safe Field-Level Deployments · Why Salesforce Deployments Fail
Was this page helpful?
Let us know how we did