Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Custom Labels entry
How-to guide

How to use Custom Labels for code-emitted strings

The successful pattern: any user-facing string in code goes through a Custom Label. The cost is one Setup record per string; the benefit is updateable wording, multi-language support, and a single surface for translators.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 18, 2026

The successful pattern: any user-facing string in code goes through a Custom Label. The cost is one Setup record per string; the benefit is updateable wording, multi-language support, and a single surface for translators.

  1. Identify the string in code that needs translation or governance

    Error messages, button labels, dialog titles, email subjects emitted from Apex or LWC. Each candidate becomes a Label.

  2. Create the Custom Label

    Setup, Custom Labels, New. Name per convention (org_prefix_purpose: SDR_INVALID_EMAIL, OPS_RECORD_NOT_FOUND). Enter the default value. Pick a category.

  3. Add translations via Translation Workbench

    For each language the org supports, enter the translated string. Translators can do this without admin access to code.

  4. Reference the Label in code

    Apex: System.Label.SDR_INVALID_EMAIL. LWC: import from @salesforce/label/c.SDR_INVALID_EMAIL. Replace the hardcoded string with the Label reference.

  5. Deploy and verify

    Deploy through the normal pipeline. Verify in the UI that the Label serves correctly in each supported language.

  6. Document the Label in the inventory

    Name, purpose, owner, code references. The inventory is what saves future developers from re-creating duplicate Labels for the same string.

  7. Audit unused Labels quarterly

    Pull the Labels list. Identify those with no code references in the past year. Retire after confirming non-use.

Label nameremember

The API identifier code references. Convention-based naming is essential at scale.

Default valueremember

The string served when no translation matches the user's language.

Categoryremember

Admin-defined grouping for organization and translator workflow.

Protected flagremember

Whether the Label is accessible from non-package code. Default false for org Labels; true for managed-package internals.

Translationsremember

Per-language values configured in Translation Workbench.

Gotchas
  • Custom Labels are not the right tool for validation rule error messages or picklist values. Use the construct-native fields, which have their own translation paths.
  • Label names cannot be changed after deployment to a packaged context. Pick the name carefully at creation.
  • Orphaned Labels accumulate. Quarterly cleanup is the discipline that keeps the surface manageable.
  • Translation Workbench access is a separate permission. Translators need it explicitly; without it, only admins can update translations.
  • Hardcoded strings in code bypass Custom Labels. The pattern only works if developers adopt the convention; without code-review enforcement, strings get hardcoded anyway.

See the full Custom Labels entry

Custom Labels includes the definition, worked example, deep dive, related terms, and a quiz.