One Salesforce org can run sales and service across several countries. To do it well, you settle a handful of org-wide settings first: multiple currencies, the corporate currency, exchange-rate handling, languages, locales, time zones and the fiscal year. Some of these cannot be switched off once enabled. So decide them before go-live, not after the first overseas deal closes. This guide walks through each decision as a buyer question.
Should a company with foreign subsidiaries still use one org?
Usually yes, when the regions share customers, products or a leadership forecast. Legal isolation or strict residency rules are the main reasons to split.
We cover that choice in depth in our single-org versus multi-org guide, so we will not repeat it here. This article assumes you have chosen one org and now need it to behave correctly in every country you sell in.
What happens when you turn on multiple currencies?
Every record that holds money gains a currency code, and Salesforce converts amounts for reporting. The change is permanent: Salesforce Help states it cannot be turned off afterwards.
Before enabling, you pick a corporate currency. It should match the currency your headquarters reports in, because every conversion passes through it. You then add each active currency and enter a conversion rate against the corporate one.
- Each record carries its own currency, defaulting to the creating user's personal currency.
- Each user has a personal currency that controls how converted amounts appear to them.
- A currency you add can be deactivated later, but Salesforce does not let you delete it from the list.
- Apex, integrations and managed packages that touch currency fields must handle the currency code correctly.
Test the switch in a full or partial sandbox first. Check every integration that writes amounts, especially ERP and billing feeds. A connector built for one currency can load wrong values silently.
Do we need dated exchange rates, and what do they miss?
Turn on Advanced Currency Management if sales leaders want closed deals valued at the rate in effect on the close date. Without it, one static rate per currency applies everywhere.
With dated exchange rates, each rate has a start date and stays in effect until the next one begins. Salesforce applies them to opportunities, opportunity products, product schedules, opportunity splits, campaign opportunity fields and reports built on those objects. Everything else keeps using the static rate.
- Collaborative forecasting does not use dated rates.
- Currency formula fields and cross-object formulas use the static rate.
- Currency fields on accounts, cases and custom objects use the static rate.
- Roll-up summaries that convert currency from opportunities to accounts or custom objects are not supported. Existing ones of that kind are disabled when the feature is turned on.
That roll-up gap matters for account hierarchies that total revenue from child accounts. Plan a flow or scheduled job to calculate those totals instead.
Who should keep exchange rates current, and how?
Finance should own the rates, because their numbers are the ones executives compare against. The mechanism can be manual entry or an automated feed.
Manual entry in Setup suits a few currencies that are refreshed monthly or quarterly. Name a finance owner and a backup, and add the update to the close calendar. Missed updates are a common reason CRM revenue disagrees with the general ledger.
For more currencies or daily rates, load them through the API from your ERP or a rate provider. Static rates live on the currency type object, and dated rates on the dated conversion rate object. Log each load and alert someone when one fails.
Will managers see revenue in dollars or local currency?
Both, if reports are set up for it. Reports can show the record's own amount and a converted column in a currency the viewer picks.
By default, a converted amount is shown in the viewer's personal currency, calculated through the corporate currency. A regional manager in Dubai can see their pipeline in dirhams while the CFO sees the same deals in US dollars. Put the display currency in each executive dashboard's title.
Agree one rule for targets and quotas. Most companies set quotas in corporate currency and let regional teams view local equivalents.
How should price books work across currencies?
Each price book entry carries one currency. A product sold in three currencies needs three entries in every price book where it appears.
An opportunity can only add products whose price book entries match its own currency. So the opportunity currency must be right before products are added.
Decide whether regions get separate price books or share one with an entry per currency. Separate books suit genuinely different regional pricing. Shared books suit a single list price converted for convenience. Our products and price books guide covers catalog design in more detail.
How do we handle several languages in one org?
Each user picks a display language for the standard interface. Your own customizations need translating separately through Translation Workbench.
Salesforce translates its standard labels for the languages it supports. Custom field labels, picklist values, custom labels, record types and similar metadata stay in the language they were built in until you add translations. Translation Workbench lets you assign translators per language, or export files for an agency and import them back.
- Keep picklist API names in one language so reports, automation and integrations stay stable.
- Translate the fields users actually see first, then help text and error messages.
- Build customer-facing email templates per language and pick the right one by the contact's language field.
Help content is a separate question. Knowledge supports multilingual articles with a master language and translated versions. Our Knowledge setup guide explains the translation workflow.
Which locale and time zone settings affect daily work?
Locale controls how dates, numbers and names are formatted for each user. Time zone controls when things happen, which matters most for service commitments.
Locale and language are independent. A German-speaking user in Switzerland and one in Germany may need different number formats. Set the org default locale for headquarters, and set each user's locale at provisioning rather than leaving it to them.
For service teams, create business hours per region, each with its own time zone and support holidays. Business hours can apply to cases, escalation rules, entitlement processes and milestones. A milestone's hours override the process hours, which override the case hours. Routing and escalation rules then respect each region's working day.
Watch scheduled automation too. Confirm which time zone each scheduled flow or batch job uses before relying on its timing.
Should we use a standard or custom fiscal year?
Keep the standard fiscal year unless finance runs a 4-4-5 style calendar or a non-standard year. Custom fiscal years cannot be disabled once enabled.
The standard option lets you pick where the year begins and whether it is named for its start or end. That suits most companies, including April or July year starts.
Custom fiscal years let you define irregular periods, but the implications are wide. Salesforce warns that existing forecasts, forecast history, adjustments and quotas from the first custom period onward are lost. You must also define each future year before you reach it. Agree the calendar with finance, then check forecasting compatibility with your Salesforce account team.
If subsidiaries close their books on different calendars, Salesforce still holds one fiscal year per org. Report on the parent company's calendar and reconcile local calendars in your finance system.
| Setting | What it controls | Reversible? | Decide before |
|---|---|---|---|
| Multiple currencies | Currency code on records, converted reporting | No, cannot be disabled | First non-corporate-currency deal |
| Corporate currency | Base for every conversion | Changeable, but review every rate | Enabling multiple currencies |
| Advanced Currency Management | Dated rates on opportunities and related reports | Yes, reverts to static rates | Designing revenue roll-ups |
| Price book currencies | Which products an opportunity can add | Yes, entries can be added or deactivated | Loading the product catalog |
| Translation Workbench | Translated custom labels, fields and picklists | Yes | Onboarding non-English users |
| Locale and time zone | Formats and when time-based rules fire | Yes, per user and per org | Setting up business hours and SLAs |
| Fiscal year type | Periods for reports, forecasts and quotas | Custom years cannot be disabled | Loading quotas and forecasts |
| Hosting region | Where org data is stored | Not a simple toggle; ask Salesforce | Signing the contract |
What about legal entities and data residency?
Model legal entities as data, not as separate configuration. Residency is a contract and hosting question you should settle with Salesforce and counsel.
A practical pattern is a legal entity field or object on accounts, opportunities and invoices. It drives sharing, document templates, tax details and the correct ERP company code. Combined with an account hierarchy, it lets regions see their own customers while leadership sees the group.
On residency, Hyperforce lets customers choose where some orgs are hosted from a list of regions. Availability, which services stay in region and what moves elsewhere vary by product and change over time. Ask your Salesforce account team for current details in writing. Privacy obligations such as consent and subject requests are covered in our data privacy guide. Treat this section as orientation, not legal advice.
How do ownership and territories change across regions?
Ownership usually follows region first and segment second. Territory design formalizes that, but it is a project of its own.
Decide early whether a global account is owned by headquarters or the region where it buys. If assignment rules are getting complicated, our territory management guide covers when Enterprise Territory Management is worth it.
What does a multi-region Sales Cloud setup look like in practice?
An Abstrakt case study shows the core building blocks working together in one Sales Cloud org.
An IT and cybersecurity firm selling in North America and the Middle East had recently upgraded to Enterprise edition. It needed multi-entity, multi-currency selling. Abstrakt set up a product catalog with separate price books for the US and Middle East, handling both one-time and recurring revenue. Location accounts rolled revenue into their parent companies, and executive dashboards plus renewal alerts rounded out the work.
The full build fit inside a 20-hour Jumpstart. Afterwards the Salesforce health check scored it at 98%. A customer-success manager was equipped to run it afterwards.
What belongs in phase one for an international rollout?
Settle the irreversible settings and the reporting rules first. Translation and regional automation can follow in later releases.
- Confirm the org strategy and hosting region with your Salesforce account team.
- Choose the corporate currency and initial currency list, then test activation in a sandbox.
- Decide whether dated rates are needed, and name the finance owner for rates.
- Agree the fiscal year type with finance before loading quotas.
- Set up regional price books or per-currency entries, plus a legal entity field.
- Configure locales, time zones and regional business hours for service teams.
- Translate the screens non-English users rely on most, and plan the rest.
