Aliaksandr Kliazovich

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.

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.

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.

It's 4 PM on release day. You hit Deploy, the spinner turns, and a few minutes later Salesforce hands you a wall of red text that explains nothing useful. The release is blocked, the team is waiting, and you're now debugging in production under pressure.

If that feels familiar, here's the good news: Salesforce deployments don't fail randomly. They fail for a handful of well-understood reasons — and once you can name them, you can prevent almost all of them.

If you’ve ever tried moving a Salesforce CPQ configuration from one org to another, you already know how painful it can be. You’re not just dealing with metadata – you’re dealing with metadata and data, which means jumping between multiple tools, exporting and importing CSVs, resolving weird ID mismatches, and praying nothing breaks.

We’ve been there too. That’s exactly why we built the CPQ Migration in mtdt.io – to make this whole process actually manageable (and dare we say, pleasant).