Locale
A locale is the per-user Salesforce setting that controls how the platform formats and reads dates, times, numbers, currencies, names, addresses, and phone numbers for that user.
Definition
A locale is the per-user Salesforce setting that controls how the platform formats and reads dates, times, numbers, currencies, names, addresses, and phone numbers for that user. The Locale field lives on the User record alongside Language and Time Zone, and each of the three is set independently. A user can read the interface in English while using a French locale, so dates render as 14 Oct 2020 instead of Oct 14, 2020 and decimals use a comma.
Locale works in two directions. It decides how stored data is displayed to the user, and it decides how typed input is parsed on edit screens before the value is saved. The platform ships a fixed list of locales tied to language and country, such as en_US, en_GB, fr_FR, de_DE, and ja_JP. Administrators choose from that list per user and set an org default; they do not invent custom locales.
How locale shapes every value a user sees and types
What the locale setting actually controls
One locale value drives a whole bundle of formatting rules. It sets the date order and style (MM/DD/YYYY for English United States versus DD/MM/YYYY for English United Kingdom), the time style (12-hour with AM and PM versus 24-hour), the decimal separator (period versus comma), and the thousands separator (comma, space, or period). It also governs currency symbol placement, the order names appear in, and address layout. Phone numbers follow locale rules too: English (United States) and English (Canada) auto-format a 10-digit or 11-digit number into (800) 555-1212, while other locales keep what you typed. You can see your own locale's exact pattern in personal settings under Advanced User Details, where the read-only audit fields render in your current format. These rules are platform-defined per locale. An admin cannot keep the French date order but swap in a period decimal separator; the locale is a packaged set, not a menu of independent toggles.
Locale, Language, and Time Zone are three separate fields
The most common confusion is treating locale, language, and time zone as one setting. They are three distinct fields on the User record, and they answer three different questions. Language decides which words the interface and help text appear in. Locale decides how dates, numbers, and currency are formatted. Time Zone decides which zone Date/Time values display in. A support agent in Berlin serving United States customers might keep Language as English, set Locale to German for familiar number formats, and set Time Zone to match the customer they are helping. Because the fields are independent, a careless setup produces a mixed experience, like an English interface showing 24-hour times the user did not expect. The platform documentation is explicit that locale does not determine the time zone. When you edit your own settings under Language and Time Zone, all three appear together precisely because each one matters and each can differ. Set them deliberately for every user rather than assuming they move together.
The org default and the currency locale
Every org has a default locale set in Setup under Company Information. A new user created without an explicit Locale inherits this default, so picking the right value for your largest user group cuts down on per-user edits. For a multi-region org, the usual pattern is to set the org default to the locale of the biggest population and then override per user for smaller regions. Currency formatting has its own related setting. The Currency Locale at the company level decides the default currency and how amounts are formatted in single-currency orgs. In orgs that have enabled multiple currencies, the Currency field on each individual record takes over and determines that record's symbol and format instead. So a Group, Professional, Enterprise, Unlimited, or Performance Edition org running multicurrency reads the record's currency, not the user's locale, for the amount itself. Keeping the org default locale, the currency locale, and the multicurrency setup aligned avoids odd combinations where a number looks formatted for one region but the currency symbol belongs to another.
ICU formats replaced the older JDK formats
Salesforce uses International Components for Unicode, known as ICU, to define its locale formats. ICU follows the Unicode CLDR standard, which keeps formatting consistent with other major platforms instead of relying on the older Java Development Kit (JDK) patterns Salesforce used historically. The platform shipped this as a release update first introduced around Spring 2020, made ICU the default for newly created orgs, and set the older JDK formats on a retirement path. The two systems format some values differently, so the switch is not invisible. A frequently cited example is the space between the time and the AM or PM marker, which ICU renders differently from JDK. Date orderings and separators can also shift for certain locales. Because of this, admins on older orgs are told to test reports, list views, validation rules, and any integration that compares formatted text before enabling ICU. You can confirm which system an org uses on the Determine Whether Your Org Uses ICU or JDK Locale Formats page in Setup. New builds already run ICU, so most teams encounter the difference only when modernizing a long-lived org.
The API stores raw values, not formatted strings
Locale formatting is a display layer, not a storage format. Salesforce stores dates as ISO 8601 (YYYY-MM-DD) and Date/Time values in UTC as YYYY-MM-DDThh:mm:ss.SSSZ, regardless of any user's locale. Numbers are stored as raw numeric values. The API returns these canonical forms, so an integration reading an Opportunity close date gets the same ISO string whether the connected user is in Tokyo or Toronto. That is the correct behavior for data integrity, because two systems exchanging data should never argue about comma-versus-period decimals. The locale layer is applied only when the platform renders a value for a human on a standard page. The practical takeaway is for custom code. Standard Lightning pages and components apply the running user's locale automatically, but custom Apex or JavaScript that builds display strings must format numbers and dates through the platform's locale-aware utilities. Hard-coding a date pattern in a Lightning component produces correct output for one region and wrong output for everyone else.
Where locale quietly breaks logic: TEXT() in formulas
Locale has a sharp edge in validation rules and formula fields that convert dates or numbers to text. The TEXT() function renders using the running user's locale, so TEXT(CloseDate) produces a different string for a United States user than for a German user. A validation rule that compares TEXT(SomeDate) against a hard-coded string like "12/31/2025" will pass for one locale and fail for another, which creates support tickets that are painful to reproduce because they depend on who is logged in. The fix is to avoid locale-dependent string conversions in logic. Compare dates with date functions (YEAR(), MONTH(), DAY()) and compare numbers as numbers rather than as their formatted text. The same caution applies to anything that parses a typed value back into a date or number, since the parser also follows the user's locale. Treat formatted text as something for humans to read, and keep your comparisons on the underlying typed values. This single habit removes a whole class of locale-driven bugs.
When a locale change takes effect
A locale change is not retroactive to the data; it only changes presentation, and it applies on the user's next page load or login. Tabs that were already open can keep showing the previous format until the user refreshes, which sometimes makes a change look like it failed when it simply has not reloaded yet. When an admin updates locale in bulk through Data Loader or another tool, each affected user picks up the new format at the start of their next session, so it helps to coordinate timing and tell people what changed. Because locale never alters stored values, switching a user from en_US to en_GB does not modify a single record; the same close date just renders as 31/12/2025 instead of 12/31/2025. That separation is reassuring during cleanup work: you can correct a wrong locale on hundreds of users without any risk to the data itself. The only real watch-out is downstream logic that already depends on a particular formatted string, which is another reason to keep logic off formatted text.
Configuring locale at the org and user level
Locale is set in two places: per user on the User record, and as an org-wide default in Company Information. Users with the right permission can also change their own locale in personal settings. Here is the admin path for both levels.
- Set the org default locale
From Setup, enter Company Information in Quick Find and select Company Information. Click Edit, choose the value in the Locale field that fits your largest user population, and save. New users created without an explicit locale inherit this default.
- Set an individual user's locale
From Setup, go to Users, open the user record, and click Edit. Set the Locale field, and set Language and Time Zone in the same screen if they should differ. Save. The user sees the change on their next page load.
- Let users self-serve
A user with access can update their own settings from personal settings under Language and Time Zone (or Personal Information), changing Locale, Language, and Time Zone independently, then clicking Save.
- Confirm the ICU format and test
Check the Determine Whether Your Org Uses ICU or JDK Locale Formats page in Setup. On older orgs still on JDK, test reports, list views, and validation rules against ICU before enabling it, since some formats differ.
Controls date, time, number, currency, name, address, and phone formatting for the user. Independent of Language and Time Zone.
Set in Company Information; inherited by new users who have no explicit locale set on their record.
Company-level setting for default currency and amount formatting in single-currency orgs; overridden by the record's Currency field in multicurrency orgs.
The format engine. ICU (Unicode CLDR) is the default for new orgs; JDK is the legacy engine on a retirement path.
- Locale does not change stored data; it only changes how values display and how typed input is parsed.
- Avoid TEXT() conversions of dates and numbers in validation rules and formulas, since they render in the running user's locale and break across regions.
- In multicurrency orgs, the record's Currency field, not the user's locale, determines the currency symbol and amount format.
- Changes apply on the next page load or login; already-open tabs may show the old format until refreshed.
Prefer this walkthrough as its own page? How to Locale in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Locale.
Hands-on resources to go deeper on Locale.
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 a user's Locale setting control in Salesforce?
Q2. How are the Locale and Language settings related on a User record?
Q3. Why should validation rules avoid TEXT() conversion of dates when the org has users in many locales?
Discussion
Loading discussion…