Alina Hubaidullina

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.

You want to push one change — a profile should use a different page layout for an object — from one org to the next, ideally across many orgs at once. The short answer: no, you don't need to deploy the whole profile. A page layout assignment is a single entry on the profile (<layoutAssignments>), and the Metadata API upserts a profile per element, so a profile containing just that one assignment deploys fine and leaves the rest of the target profile untouched. That still leaves the questions every admin automating this runs into: will it wipe my other assignments? Do I need the layout and the record types too?

Can you deploy picklist values between Salesforce orgs? Search it and you hit a wall of half-answers: the values seem not to come across, someone tells you to "just deploy the whole object," and global value sets are apparently a separate thing entirely. The short answer is yes — and the confusion comes down to where a picklist's values actually live.

Ask how to deploy a Salesforce profile — the System Administrator profile especially — and you'll get a chorus of warnings: it wipes permissions, it comes over empty, it strips your settings. The fear is earned. The Metadata API reads a profile as a single all-or-nothing document, so the way you deploy it decides whether you ship a clean change or a mass lockout — and the safest way is to scope the profile to only the components you're deploying, so anything you didn't include is never touched on the target.

You deploy a custom object and one of its fields throws … is not in package.xml — even though the object is right there in your manifest. Or the deploy succeeds, but the field never shows up in the target. Both trace back to one fact: a custom field and the object it lives on are separate metadata components, and your deployment has to keep the two in agreement on every field.

You deploy a profile or permission set to another org and Salesforce throws it straight back:

Unknown user permission: SendExternalEmailAvailable

The profile is valid and the permission is real; the target org simply doesn't recognize the name. That's because the permission only exists in an org once the feature behind it is turned on — here, SendExternalEmailAvailable needs Email Deliverability set to "All emails" — and the same cause is behind every "Unknown user permission" error.

You want to retire a record type, so you add it to a destructive deployment — and Salesforce throws it right back at you. Record types are one of the few components the Metadata API refuses to delete: put one in destructiveChanges and Salesforce hard-rejects it with Cannot delete record type through API, every time. The supported path instead is to deactivate it — deploy it with <active>false</active> — then delete it manually in Setup once no records reference it.

You build a Lightning page — a FlexiPage — assign it as the record page for an object, deploy it to the next org, and it doesn't show up. The page is there; the assignment isn't. Or you try to move the assignment and the deploy hard-fails instead. The behavior looks random until you see the cause: Salesforce stores a Lightning page assignment separately from the page, across two different metadata types depending on how the page is scoped. Nearly every assignment does deploy through the Metadata API — org defaults on the object, app/profile/record-type activations on the Custom App — as long as you deploy it from the right container; the one exception is a record-type-specific assignment with no app or profile, which has no metadata field to carry it.

Take a workflow that references a Person Account record type and move it to another org. Sometimes it deploys cleanly; sometimes Salesforce rejects it outright. The deciding factor is how the workflow uses the record type: a rule's entry criteria that filter on the record type deploy without issue, while a field update that tries to set the record type is rejected by Salesforce itself, regardless of the tool you deploy with.

You migrate records — accounts, cases, CPQ configuration — from one org to another, and Salesforce throws back every row with the same error:

INVALID_CROSS_REFERENCE_KEY: Record Type ID: this ID value isn't valid for the user: 012d2000009YkJOAA0

The records were fine in the source. Their record type IDs are the problem, for one of two reasons: the ID is org-specific and doesn't exist in the target, or the target record type exists but isn't assigned to the user running the migration. The fix is to remap each record's RecordTypeId to the target org's equivalent by Developer Name, and make sure the loading user has that record type assigned — mtdt.io does the remapping automatically and flags any assignment you still need to grant.