Every email logged to a case, a contact, or a record lives in Salesforce as an EmailMessage. Those messages are some of the most compliance-sensitive data you hold — e-discovery, audits, disputes all turn on "what was actually sent." Yet they sit in Salesforce with finite storage and retention, and a standard backup doesn't single them out.

mtdt.io backs up your EmailMessages incrementally into your own database and S3 — a queryable email archive you control.

You back up your metadata. You back up your records. But there's a third pile of data most teams never protect: Files — the attachments, uploaded documents, images, and signed PDFs stored as Salesforce Content Versions. They're often the largest data in the org, the most expensive to store, and the least backed up.

mtdt.io backs them up to your own S3 — a copy of your Salesforce files in storage you control.

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.

A deployment succeeds, everyone moves on — and an hour later a key flow is misfiring in production. Now what? With native Salesforce tooling, the honest answer is: you rebuild the previous state by hand, under pressure, while production misbehaves.

There's a better answer. Here's why Salesforce rollback is genuinely tricky, and how to turn it into a single click. mtdt.io does it by capturing a rollback point — a snapshot of the target org's metadata — right before a deployment runs; if the release goes wrong, you open the deployment and click Rollback to restore that pre-deployment state.

A few years ago, "Salesforce DevOps" mostly meant "please stop using change sets." In 2026 it means a connected stack of version control, safe deployment, backup & recovery, quality, data, and governance — practices and tools that take a change from a developer's sandbox to production safely, repeatably, and with a way back if something breaks.

If you're assembling (or upgrading) that setup, this is the map: what each layer is for, and how they fit together.

Ask a Salesforce team what their disaster recovery plan is and you'll usually get one of two answers: "Salesforce handles that," or an uncomfortable silence. Both are a problem.

Salesforce is one of the most reliable platforms on earth — but "the platform is up" and "your data and configuration are recoverable" are two very different guarantees. This is a practical playbook for the second one: what to protect, how to think about it, and exactly what to do when something goes wrong.

"Just deploy the one thing I changed" sounds simple. On Salesforce, it's one of the easiest ways to quietly break production.

The problem isn't deploying less — it's that Salesforce treats what you leave out as a decision. Here's why partial deployments are risky, when you actually need them, and how to do field-level deploys without the landmines.

Here's a workflow most Salesforce teams know too well: make a change, deploy it, then remember to retrieve the metadata and commit it to Git so the repo stays current. That last step is the one that slips — and every time it does, your repo and your org drift a little further apart.

It doesn't have to be a separate, forgettable chore. Your deployment can land in Git automatically.