Local Name
A Local Name is a Salesforce field that stores a person's or account's name in the native script of a local language, kept alongside the standard name field that usually holds an English or romanized version.
Definition
A Local Name is a Salesforce field that stores a person's or account's name in the native script of a local language, kept alongside the standard name field that usually holds an English or romanized version. The standard objects Account, Contact, Lead, and User support local name fields, with labels such as First Name (Local), Last Name (Local), and Account Name (Local). The standard field holds one representation, and the local field holds the other, so a single record carries both forms of the same name.
Local Name fields matter most in markets where people and companies are known by a name written in their own script. A contact recorded as Taro Yamada in the standard fields can carry the kanji form in the local fields. Salesforce stores the value in the account's or user's language, and these fields do not change anyone's user language settings. Without local name fields, an org has to choose one script and drop the other, which weakens search and the customer experience in those regions.
How Local Name fields work across objects
Which objects and fields are involved
Local name support is built into four standard objects: Account, Contact, Lead, and User. Each gets a local counterpart for its name fields. On person objects like Contact, Lead, User, and Person Account, you see fields labeled First Name (Local), Last Name (Local), and, where middle names are enabled, Middle Name (Local). On Account, the field is Account Name (Local). The label always carries the (Local) suffix so admins and users can tell the two representations apart on a layout. The standard field and the local field are separate columns on the same record, not a single combined value. That separation is what lets one record hold both a romanized form and a native-script form at the same time. The two forms describe the same person or company, so there is no duplicate record and no merge step. Because these are real fields, they appear in reports, list views, search, and the API once an admin exposes them, and they behave like other text name fields for filtering and sorting. The standard field stays required as usual, while the local field is optional unless your business rules say otherwise.
Turning the fields on in Setup
Local name fields are not visible by default, even though the storage exists on the supported objects. An admin has to surface them in two places before a user ever sees them. First, add the field to the page layout. From Setup, open Object Manager, pick the object that has the local name field, open Page Layouts, edit the layout, then drag the local name field (for example First Name (Local)) into the appropriate section. Second, grant access through field-level security so the right profiles can read and edit the value. You manage that through Field Accessibility or the field-level security settings on the field itself. Skip either step and the field stays hidden for that profile, which is the single most common reason admins think local names are missing. Plan the rollout by profile, since a Japan sales team and a global executive team often need different visibility. Local name fields are available across editions, with Database.com being the documented exception for business accounts. Confirm your edition and object support before you promise the feature to a regional team.
Searching across both name forms
The practical payoff of local name fields shows up in search. Salesforce makes both the standard name and the local name findable, so a user who types the romanized form and a user who types the native-script form can both land on the same record. A teammate in a London office can search Taro Yamada while a teammate in Tokyo searches the kanji, and they reach one shared contact. That bilingual searchability is the reason orgs prefer local name fields over the workaround of stuffing two scripts into one field or creating a second record. Both approaches break reporting and create duplicate-management headaches. With local name fields, the record stays single and clean, and each audience searches in the script that feels natural to them. The benefit extends to global support teams who may receive a case under one spelling and need to match it to a record entered under another. Keep in mind that search depends on the value actually being populated, so a record with an empty local field is only findable by its standard name until someone fills the local field in.
How local names behave in reports
Reporting treats local name fields a little differently depending on the report type, and the difference trips people up. When a local name field is empty on a record, a standard report falls back and shows the value from the matching standard name field instead of a blank. A custom report does not do that fallback; it shows an empty value when the local field has no data. This matters when you build dashboards for a regional team. If you expect every row to show a native-script name and some records were never populated, a custom report exposes those gaps as blanks, while a standard report quietly hides them behind the romanized name. Decide which behavior you want before you choose the report type. For an audit of which records are missing local names, a custom report is actually the better tool because it makes the blanks visible. For a clean executive view that should never show an empty cell, the standard report fallback is friendlier. Either way, both the standard and local name fields can be added as columns, grouped on, and filtered, so you can build side-by-side views that show each representation in its own column.
Person Accounts and the related name settings
Person Accounts get the same local name treatment, which makes sense because a Person Account blends Account and Contact data into one record for business-to-consumer scenarios. The person-style local fields, First Name (Local) and Last Name (Local), apply to the individual side of the record. If your B2C org runs in a market that uses a non-Latin script, enabling and exposing these fields gives each individual customer both a romanized and a native-script name on a single record. Local name fields also sit near a separate but related feature: customizable person names. Through Setup, User Interface, you can enable Middle Names and Name Suffixes for person objects, which adds Middle Name and Suffix fields to Contacts, Leads, Person Accounts, and Users. When middle names are on, a Middle Name (Local) field becomes part of the local set too. These name settings are independent toggles, so you can run local names without suffixes, or both together. Be aware that middle names and suffixes are not shown in every feature area, so review the supported surfaces before relying on them in places like activities or campaigns.
Data hygiene and integration mapping
The most damaging mistake with local name fields is mapping data into the wrong slot. During an import or an integration with an external CRM, ERP, or billing system, it is easy to load the romanized name into the local field or the native-script name into the standard field. When that happens, search still works mechanically, but the customer-facing experience and any layout that expects a specific script now shows the wrong form. Document the field mapping for every integration and data load, and write down which system owns which representation. Validate a small sample after the first load before you trust the full migration. If you adopt local names in an org that already has thousands of records, treat the population of native-script values as its own data project rather than an afterthought, because the standard fields will already be full and the local fields will start empty. Training matters too. Teach data-entry users which field is which, and consider making it routine to capture both forms on new records so you do not accumulate a backlog of records that carry only one script and undercut the bilingual search you turned the feature on for.
Expose a Local Name field to your users
Local name fields ship on Account, Contact, Lead, and User, but they are hidden until an admin exposes them. Use this flow to make a local name field visible to the right users on one object. Repeat per object and per profile as needed.
- Open the object in Object Manager
From Setup, go to Object Manager and select the object that has the local name field, for example Contact or Account.
- Add the field to a page layout
Open Page Layouts, edit the layout your users see, then drag the local field such as First Name (Local) or Account Name (Local) into a section.
- Grant field-level security
Open the field and set field-level security, or use Field Accessibility, so the profiles that need the local name can read and edit it.
- Verify per profile
Log in as a user on each affected profile, or use the layout assignment view, to confirm the field appears and is editable where expected.
The local field only shows where you drag it; assign the right layout to each profile and record type so the correct audience sees it.
Read and edit access is controlled per profile; without it the field stays hidden even after it is on the layout.
Optionally enable Middle Names and Name Suffixes under Setup, User Interface, which extends the local set with a Middle Name (Local) field.
- Adding the field to a layout is not enough; without field-level security the profile still cannot see it.
- Custom reports show an empty value when a local name is blank, while standard reports fall back to the standard name field.
- Database.com is the documented exception for business account local names; confirm your edition before promising the feature.
- Loading the romanized name into the local field is a frequent import error that quietly corrupts the customer-facing name.
Prefer this walkthrough as its own page? How to Local Name in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Local Name FieldsSalesforce
- Enable Local Name fieldsSalesforce
- Account Local Name FieldsSalesforce
Straight from the source - Salesforce's reference material on Local Name.
- Local Name FieldsSalesforce
- Add Local Name Fields to a Page Layout in Lightning ExperienceSalesforce
Hands-on resources to go deeper on Local Name.
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. What does the Local Name field store relative to the main Name field on a record?
Q2. Where does an admin turn on Local Name fields for Account, Contact, Lead, and User?
Q3. What is the most important search benefit of enabling Local Name fields?
Discussion
Loading discussion…