12 posts tagged with "Metadata"

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.

"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.

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 managed a Salesforce environment for a long time—or inherited one from a previous consultant—you know the feeling. You start to wonder: How many of these Apex classes are running on ancient API versions? Are our automated flows actually active? Why did that scheduled job fail silently three days ago?

Maintaining a Salesforce org shouldn’t feel like detective work. mtdt.io Healthcheck answers that question directly: it's a centralized monitoring suite that scans your org for inactive flows, outdated Apex API versions, lost users, timezone mismatches, Apex job failure rates, storage utilization, and license expirations — surfacing the issues before they cause an outage or a deployment failure.

We’ve all been there: a critical migration fails or a user can’t save a record because of the dreaded "Storage Full" notification. In the Salesforce world, hitting your data limit usually means two things: a frantic cleanup session or a very expensive invoice for extra gigabytes.

But beyond the cost, there’s a bigger question of Control. Does your security team really want your historical backups sitting in a third-party "black box"? Or should that data live in your own corporate-governed AWS, Azure, or S3 bucket?

At mtdt.io, we believe you should own your data—literally. We don’t want to be your "data jailer." Instead of forcing you to use our storage, we let you plug in your own cloud providers. This gives you the freedom to archive, protect, and manage your Salesforce data on your own terms.

Smarter, safer, and fully controlled Salesforce metadata delivery

In real Salesforce projects, deployments rarely happen in perfect sequence. You might deploy several features to UAT at different times – Feature A, Feature B, and Feature C – but only A and B are approved for production.

Until now, managing such partial releases meant juggling change sets, comparing metadata manually, or rebuilding deployment packages from scratch.

mtdt.io introduces a better way: Archives.

If you’ve ever deployed something to production in Salesforce and thought, “Oh no, I should’ve changed that one thing…” – this is for you. With mtdt.io, you can edit your components right before deploying, no need to go back to the sandbox or repackage everything. It’s like having a final review button with actual power.

The free plan of mtdt.io offers real deployment power without upfront cost. It’s perfect for:

• Salesforce Admins who need a simple, reliable tool to manage metadata deployments.
• Developers aiming to resolve deployment conflicts without endless trial and error.

You don’t need a DevOps engineer to get started with mtdt. With a clean interface and smart automation, even non-technical users can confidently manage releases.

When it comes to Salesforce deployment, teams often start with native tools like Change Sets. However, as your development processes scale, the need for a more powerful, automated solution becomes clear. That’s where mtdt.io comes in — a platform designed to simplify and streamline Salesforce deployments.

In this article, we compare mtdt and Change Sets to help teams understand the key differences and decide which tool best fits their workflow.