44 posts tagged with "DevOps"

You migrated your CPQ configuration to the new org. The product rules don't fire. The price rules point at nothing. Half the product options seem to have vanished — and nothing errored. The records are just sitting there, quietly not working.

Because Salesforce CPQ configuration isn't metadata. It's data — and data carries Salesforce IDs that are different in every org.

You add a record type to a deployment, ship it, and Salesforce stops you cold:

Global value set 'Tier__c' in record type 'Partner' on the entity 'Account' cannot be resolved

or the one everyone ends up searching for:

Picklist value: Archived in picklist: RT_Status__c not found

The record type deployed fine in your source org. In the target, it can't find a picklist field — or a value — it relies on.

You update a Schedulable Apex class, deploy it to an org where it's running, and Salesforce stops you:

This schedulable class has jobs pending or in progress.

The class is locked while it has a scheduled job. And even once you get past that, the schedule doesn't come with it — Salesforce deploys the class, not the running job.

You spent the afternoon building in a sandbox — a couple of fields on Account, a tweak to a flow, a new permission set, an Apex class. Now you need to move it to the next org. Quick question: what exactly did you change?

Salesforce won't tell you on its own — but a source-tracked org (a scratch org, or a sandbox with source tracking enabled) already records every metadata change you make. mtdt.io's Source Tracking reads that log: start a Record Session, build normally, and it lists every component you touched by name — ready to retrieve, download, deploy, or open as a pull request, no CLI required. Without it, you rebuild the list from memory, click through Setup hunting for every component, and hope you didn't miss the one field that quietly breaks everything downstream.

Most Salesforce metadata is text — XML you can read, diff, and merge. Static resources aren't. They're files: a logo, a JavaScript library, a CSS bundle, a zipped folder of assets. And the moment a deployment has to carry a binary, the usual text-and-files workflows start to creak.

You deploy the metadata, the release goes green — and then someone opens the Developer Console on the target org to run "that one script": re-schedule the nightly job, set a custom-setting value, kick off a backfill. It's a manual step, it's easy to forget, and forgetting it means the deploy looked successful but the org isn't actually finished.

mtdt.io closes that gap: it can run a block of anonymous Apex on the target org automatically, the moment a deployment succeeds.

The fastest way to break production is to let everyone deploy to it. As a team grows, "anyone can push anything, anytime" stops being agility and starts being risk. What you want instead is separation of duties: people propose changes, and a smaller set of trusted reviewers sign them off.

mtdt.io's deployment approvals build that directly into the deploy flow — role-based, enforced at the moment of deploy, with extra protection for your most important orgs.

Most Salesforce deployment failures aren't mysterious. A flow references a field that isn't in the package. A profile change quietly removes access. There's no way to undo it if it goes wrong. These are predictable problems — and yet they usually surface the worst way: after you click Deploy, as a red error or a wave of "I can't see X" tickets.

What if you saw them before? That's what mtdt.io's pre-deployment checks do — run a set of analyzers against your target deployment and flag anything risky while you can still fix it cheaply.

Salesforce makes you hit 75% Apex test coverage to deploy to production. It's an easy target to game — and it proves only that your code runs, not that it's fast, safe, or maintainable. Coverage is not quality.

The issues that actually bite — a SOQL query inside a loop, an unhandled exception, a hardcoded ID, a sharing leak — sail straight through a coverage check and surface later as governor-limit errors, slow pages, or a security finding. Static analysis is how you catch them before they ship: mtdt.io runs the industry-standard analyzer PMD across your org's Apex, on demand or on a schedule, and reports every violation ranked by severity.

Salesforce DevOps Center was a genuine leap forward. It dragged teams off change sets, put Git at the center of releases, and made source-driven development approachable for admins and devs alike — for free. If you're using it today, you made a good call.

But there's a pattern almost every growing team runs into: somewhere around the 6–12 month mark, DevOps Center starts to feel less like a platform and more like a ceiling. DevOps Center is a starting point, and outgrowing it is the normal arc for a maturing team.