51 posts tagged with "Deployment"

The Rename Tabs and Labels settings (Setup → Rename Tabs and Labels) — the renamed tab, object, and field labels your users see — are stored in the CustomObjectTranslation metadata type, one component per object per language (for example Account-en_US). Because it's metadata, it deploys through the Metadata API, so you can move those renames org-to-org instead of re-typing them by hand in every sandbox and production org. mtdt.io treats CustomObjectTranslation as a first-class type: compare two orgs, see the renamed labels in the diff, and deploy them across.

Deploying between Salesforce environments means moving metadata — objects, fields, Apex, flows, profiles, layouts — from a source to a target. The catch most people hit first: change sets only work between a production org and its own sandboxes, so the moment you need to deploy between two unrelated orgs, a Git branch, or a backup, you have to step up to the Metadata API (via SFDX, the CLI, or a tool like mtdt.io), which deploys between any two connected orgs regardless of type or lineage. This guide walks every source→target combination, when you'd use each, and what won't travel on its own.

You deploy a Certificate, a Named Credential, or an Auth Provider from one Salesforce org to another. The deploy goes green — and then the integration that depended on it is broken. It's not your deployment tool: the Metadata API never carries a component's secret, by design. The piece that makes the component work stays behind.

You set up a few Apex Test Suites, you like how they group your tests — and then you go to move them to another org through a change set, and there's no option for them anywhere in the component list. You're not missing a setting: change sets simply don't carry test suites. The Metadata API does, though — and that's the path mtdt.io deploys through, moving the suite org→org with its member test classes recommended so nothing lands broken.

You've got a batch of new objects to move from sandbox to production, but you're not ready to give users access to them yet. The natural plan: deploy the objects now, deploy the permissions later. The natural worry: if you include profiles, do you grant access too early — or worse, overwrite production's profiles wholesale?

You can absolutely split it: deploy the objects with no profile in the package, and Salesforce's own default keeps every user's access at none until you deploy a profile later. The trick is doing it without the two traps that make people nervous.

Search "error deploying reports" and you hit the same wall thousands of others have — a terse failure with no obvious cause:

Action: NO ACTION Result: FAILED Problem: filterlanguage: Invalid value specified: 1

Reports look like simple metadata, so the errors feel out of proportion. Most report-deploy failures trace back to one of a few specific causes: a Filter Language set for a Translation Workbench language the target doesn't have, a missing report folder, a missing Custom Report Type, or a currency filter that assumes multicurrency is on. Two of those are Salesforce platform rules no tool can deploy around; the rest — the folder, the report type, the referenced fields — mtdt.io resolves automatically. Here's the whole picture, and where a tool can actually help.

A dependent picklist narrows its options based on another field — pick a Region and the Country list filters to match. That convenience is stored as a value-by-value mapping plus a pointer to the controlling field, and moving it to another org is where it falls apart: deploy the dependent field on its own and Salesforce throws it back with no CustomField named … found. The fix is to deploy the controlling field in the same deploy as the dependent field, so the reference resolves — mtdt.io deploys the value mapping intact and recommends the controlling field automatically, since Salesforce's own dependency graph doesn't model that link.

You need to delete a field, an object, or a class from a target org — and your SFDX deploy quietly leaves it in place. A source deploy (sf project deploy start --source-dir, formerly force:source:deploy --sourcepath) deploys the components it finds in your source directory. Removing something is a separate instruction the source format doesn't carry — the manual path is a hand-authored destructiveChanges.xml paired with an empty package.xml and a pre/post ordering flag. mtdt.io turns that into a checkbox: pick what to delete, get the manifest built for you, and choose before-or-after deploy ordering with one radio.

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?