Rename Tabs and Labels
Rename Tabs and Labels is a Salesforce Setup page where an administrator changes the display names of standard objects, their tabs, and their standard fields to match the words a company already uses.
Definition
Rename Tabs and Labels is a Salesforce Setup page where an administrator changes the display names of standard objects, their tabs, and their standard fields to match the words a company already uses. From Setup, you enter "Rename Tabs and Labels" in Quick Find and edit any object in the list. The platform keeps the original API names underneath, so reports, automation, and integrations are unaffected.
The point is adoption. If your team says Customers, Deals, and Tickets instead of Accounts, Opportunities, and Cases, the renamed labels meet people where they already think. You can also enter labels in other supported languages on the same page, which makes this feature double as the place to translate standard objects.
How renaming works under the hood
What you can rename, and what stays fixed
You can rename most standard tabs and objects, plus the standard fields that sit on them. Accounts, Contacts, Leads, Opportunities, Cases, Campaigns, Solutions, and similar objects all appear in the list. A few items are off limits by design. The Forecasts tab is not available for renaming. System audit fields such as Created By and Last Modified By are purposely omitted, because they track platform information that should read the same everywhere. Custom objects and custom fields do not appear here either; you set their labels in the object manager when you build them. When you open an object, Salesforce asks for both a singular and a plural label, because the interface uses each in different places. A list view header wants the plural, while a record page button often wants the singular. There is also a checkbox to mark labels that start with a vowel sound, so help text and system messages read "an Asset" rather than "a Asset". Spend a minute on these small fields; they are what make the rename feel native instead of half finished.
Labels change, API names do not
The most important thing to understand is the split between the label and the API name. Renaming changes only the human-facing label. The underlying object and field API names stay exactly as Salesforce shipped them. Account is still Account in SOQL, in Apex, in formula fields, and in every integration payload. This is what makes the feature safe to use. You are not migrating data or breaking references; you are changing a presentation layer. That split has a practical consequence for anyone learning or supporting the org. Documentation, Trailhead modules, Stack Exchange answers, and Salesforce Help all use the original names. A user who only ever sees "Deal" can be confused when a tutorial talks about Opportunities. The fix is to write down both names in your internal admin notes, so the team can map your vocabulary back to the standard one when they read external material. Renamed labels reach most of the UI: tabs, list views, the search bar, report column headers, and many standard error messages. A handful of hardcoded strings in Salesforce help content will still show the original word.
The two-in-one role with translation
Rename Tabs and Labels quietly does a second job. The same page lets you pick a language and supply standard object, tab, and field labels for that language. This matters because standard objects are not editable inside the Translation Workbench. If your org runs in French or Japanese and you want "Compte" or to translate a standard field label, this Setup page is where that text lives, not the Translation Workbench grid. The division of labor is worth memorising. Use Rename Tabs and Labels for standard objects, their tabs, and their standard fields, in any supported language. Use the Translation Workbench for everything custom: custom object labels, custom field labels, picklist values, validation rule error messages, and custom labels. Mixing them up is a common cause of "why won't this translate" tickets. A label that refuses to change in the Translation Workbench is usually a standard one that belongs on the Rename page instead.
Where renamed labels actually appear
After you save, the new label propagates broadly, but not into literally every corner. Tabs in the navigation bar update. List view names that reference the object update. The global search scope picker shows your word. Report and dashboard column headers that pull the object or field label reflect the change. Many standard validation and system messages swap in the renamed term too, which is a nice touch for end users who read an error and see familiar language. Some surfaces are stubborn. Standard report type names, certain admin-only Setup pages, and some help bubbles keep the original Salesforce wording, because they are aimed at administrators rather than business users. Custom components you build, such as Lightning web components or screen flows with hardcoded text, will not auto-update either; they show whatever string you typed. Plan a quick audit of your key page layouts, list views, and any custom buttons after a rename, so a leftover "Opportunity" label does not sit next to your shiny new "Deal" tab.
A worked example: Accounts to Clients
Say a wealth management firm wants Accounts to read as Clients. From Setup, the admin opens Rename Tabs and Labels and clicks Edit next to Accounts. They set the singular label to Client and the plural to Clients, leave the vowel-sound box unchecked, and save. Within moments the Accounts tab reads Clients, the "New Account" button becomes "New Client", and the list view that was "All Accounts" now reads "All Clients". The firm operates in Canada and also needs the French label. On the same page the admin switches the language selector to French, enters "Client" and "Clients" for that locale, and saves again. French-language users now see the translated tab while English users keep theirs. Nothing in the data model moved. A scheduled Apex job that queries Account runs unchanged, a Salesforce report built on the Account object still works, and an integration writing to the Account API name is untouched. The only thing that changed is the word people read, which is exactly the goal.
When to rename, and when to leave it alone
Rename early in an org's life. Vocabulary settles as teams adopt the system, and a label change that is trivial in week one can feel disruptive a year later, once users have built muscle memory and written their own internal docs. If you know on day one that the business says Tickets rather than Cases, do it before go-live. Resist the urge to rename for its own sake. Every renamed label adds a small translation tax for anyone who reads Salesforce documentation, and frequent ad-hoc changes confuse a settled team more than they help. A good rule is to rename only the handful of objects where your internal word is genuinely different and well established, then stop. Keep a short record of each change, including the original name, the new label, and the date. That record pays off the first time you open a support case and the agent asks about "Opportunities" while your screen says "Deals".
How to rename a standard object or tab
Renaming is done entirely in Setup and takes effect almost immediately. You change the label, not the data, so it is safe to do in production with a little planning.
- Open the Rename page
From Setup, type "Rename Tabs and Labels" in the Quick Find box and select it. You see a list of standard tabs and objects that support renaming.
- Edit the object
Click Edit next to the object you want to rename, for example Accounts. Leave the language selector on your default to rename in English, or switch it to a supported language to translate.
- Set singular and plural labels
Enter both the singular and plural display names. Mark the "Starts with a vowel sound" box if the new word begins with a vowel, so generated messages read correctly.
- Adjust standard field labels
Continue through the wizard to rename the object's standard fields if needed. Save when done; the new labels appear across tabs, list views, and reports within moments.
Choose your org default to rename in English, or pick a supported language to supply translated labels for that locale.
Both are required because the UI uses each in different spots; a list header wants plural, a button often wants singular.
A checkbox that fixes grammar in system messages so users see "an Asset" instead of "a Asset".
Optional per-field overrides reached inside the same wizard, excluding audit fields like Created By that cannot be renamed.
- The Forecasts tab and audit fields such as Created By and Last Modified By cannot be renamed.
- Only the label changes; API names stay the same, so SOQL, Apex, and integrations are unaffected.
- Custom objects and custom fields are not renamed here; set their labels in the object manager and translate them in the Translation Workbench.
- Salesforce Help, Trailhead, and some admin Setup pages keep the original names, so document both your label and the standard one.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Rename Tabs and Labels.
Hands-on resources to go deeper on Rename Tabs and Labels.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Rename Tabs and Labels without writing code?
Q2. In which area of Salesforce would you typically find Rename Tabs and Labels?
Q3. What is the primary benefit of Rename Tabs and Labels for Salesforce administrators?
Discussion
Loading discussion…