44 posts tagged with "DevOps"

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.

In Salesforce, every user has exactly one profile and can have many permission sets. A profile sets the baseline — and the settings that can only have one value per user, like default app, record types, page layout assignments, and login hours. A permission set grants additional access on top and stacks additively, so you can assign the same set to many users. The model Salesforce now recommends is minimal profiles plus permission sets (composed into permission set groups), and that's where the ecosystem is heading — though, as of 2026, there's no deadline forcing it.

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.

There are two kinds of Salesforce admins: the ones who back up their sandboxes, and the ones who haven't been through an accidental refresh yet. A sandbox refresh can't be undone, and as of 2025 Salesforce support no longer recovers an overwritten sandbox — so the only way back is a metadata backup you made before the refresh, which mtdt.io runs on a free, scheduled basis. The day someone refreshes the wrong sandbox — weeks of unreleased config, gone in one click — you find out which kind of admin you are.

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.