44 posts tagged with "DevOps"

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 start a deployment and it just sits there — no error, no progress, only a spinner. Or, on a busy org, it comes back after a long delay with a cryptic LIMIT_EXCEEDED. The usual reason: something else is already deploying to that org, and Salesforce runs only one deployment at a time.

You open a permission set, go to Flow Access, and try to add a flow — but the Available Flows list is empty. Your org has plenty of flows; not one of them shows up to grant. That's by design: the list only shows flows that are active and run in the running user's context, so an inactive flow or one set to system context won't appear. The bigger problem comes later — once a permission set grants flow access, deploying it to an org missing that flow hard-fails, and mtdt.io fixes this by recommending the flow as a dependency before the deploy runs.