Try it out for free on SimpleT.

What does it do?

Exclude Metadata applies user-defined rules during the retrieve phase. Matching fields are skipped before reaching SimpleTranslate — they never appear in queues, consume credits, or affect statistics.

Only relevant fields are processed, keeping queues clean across every environment.

The Problem: Unfiltered Metadata Entering the Translation Workflow

In most Salesforce orgs, a large portion of metadata was never meant to be translated. Without filtering at the source, these fields end up in translation queues regardless.

Common challenges include:

• Internal API names like IPC_OrderManagement or SF_InternalRef appearing in translation workflows

• Third-party managed package fields consuming credits despite shipping with their own translations

• System fields with stable labels being flagged unnecessarily

• Fields owned by packages with a separate translation pipeline mixing into the main queue

These issues create noise, waste translation credits, and slow down the teams managing the workflow.

The Solution: Rule-Based Metadata Filtering

Exclude Metadata gives admins precise, per-environment control over what enters the translation workflow — without touching the underlying Salesforce configuration.

Two rule types are supported and can be combined freely:

Prefix (API Name) — A regular expression matched against the field API name. For example, IPC_.* excludes IPC_OrderManagement, IPC_Account__c, and any other field whose API name starts with IPC_.

Namespace — A literal namespace prefix matched against the field namespace. For example, nsp excludes nsp__CustomField__c, nsp__Account__c, and every other field belonging to the nsp managed package. Namespace rules also catch nested fields inside larger metadata containers.

How to Set It Up

• Open the Metadata Blacklist: Go to Org Credentials in the navigation bar, locate your environment in the credentials table, open its action menu, and select Metadata Blacklist.

• Add a rule: Select Add Rule, choose the rule type (Prefix (API Name) or Namespace), enter your pattern, and select Save. Example placeholders guide each type: IPC_.* for Prefix, nsp for Namespace.

• Edit or delete a rule: Double-click any rule row to edit inline, then Save. To delete, select the delete control on the row and Save.

• Activate or deactivate the rule set: Use the Active toggle in the dialog footer to enable or disable all rules at once. Rules are preserved when inactive and can be re-enabled at any time.

Key Business Benefits

1. A Clean, Noise-Free Queue

Excluded fields produce no markers, logs, or UI noise — the queue only shows fields matching active rules.

2. Fully Isolated per Environment

Rules apply to a single environment only. Sandbox rules never affect Production.

3. Safe, Validated, and Performant

Invalid regex is rejected before save, rules are pre-compiled for speed, and unsaved changes stay highlighted.

Tips

• Test new regular expressions on a small set of metadata before applying them to a Production environment

• Use Namespace rules for managed packages and Prefix rules for ad hoc patterns owned by your team

• Use the Active toggle to temporarily include all metadata for an audit without losing the existing rule set