Global Salesforce template: how much country fits?

A global Salesforce template is the shared core of processes, data model, automation and permissions that every country of a worldwide rollout adopts. My guideline: every country is at least 80 percent identical to the template, and the delta per country stays as small as possible. Deviations from law, tax, language and real differences in the business are justified. Every deviation needs a request, a reason and an approval, and it belongs in configuration instead of code per country. Without these rules the template turns into a collection of country solutions after three countries.

Why does a global template fall apart?

The strategic goal of a worldwide rollout is usually to harmonise processes. At the start everyone agrees. From the second country on, the exceptions arrive: in France inside sales needs an additional field, in Italy quote approval runs through one more level, and in the US the subsidiary has a different name and trades under a different brand.

Each exception is small. Together they have three consequences:

• Every change gets more expensive. A new feature has to be tested in every country variant. With ten countries that have their own flows, one release is ten releases.
• Reports across countries stop adding up. If a status means something different in every country, worldwide order intake is an estimate.
• New countries get slower. Instead of adopting the template, every new country picks the variant it likes best.

I describe the order of countries in detail in Manufacturing Cloud global rollout. This article is about the question every country asks again: may this deviation go into the system?

Which deviations are justified?

I sort every request for a deviation into one of five groups:

Reason	Example	Into the template?
Law and tax	e-invoicing mandate, tax number, retention periods	yes, as country configuration
Language and formats	translations, address formats, currency	yes, through standard features
Brand and legal entity	subsidiary trades under a different name	yes, as master data, not as a process
Different business	country sells through dealers instead of directly	yes if several countries are affected, otherwise review
Habit	“the field has always been at the top here”	no

The last group is the largest, and the hardest, because it rarely goes by that name. A request out of habit almost always comes with a business reason. A good test question is: what does it cost the country to adopt the template’s process? If the answer is “getting used to it”, it is habit. If the answer is “an invoice the tax office will not accept”, it is law.

The fourth group deserves a second look. If one country sells through dealers and the others sell directly, that is a second variant of the sales process. If the same variant appears in several countries, it belongs in the template, and only once.

Country differences belong in configuration, not in code

The technical rule is simple: country differences belong in configuration, not in code or separate flows per country.

• Values per country in custom metadata types. Approval limits, VAT rates or required fields per country sit in a table. The automation reads the value for the record’s country. A new country is then a new entry, not a new release.
• Translations through Salesforce’s translation features, not through extra fields per language.
• Record types only for real process variants, not per country. Ten countries with one record type each are ten page layouts that drift apart.
• Visibility by country through roles and sharing rules, as described in the permission concept.

These rules belong in the development standards, so every partner who rolls out a country knows them.

Who decides on deviations?

A country requests a deviation in writing: what it needs, why, and what it costs to adopt the template instead. The decision is made by a global process owner together with the architect on the client side. It goes into the decision log, so the next country does not ask the same question again.

Two rules help. First, the country carries the follow-up cost of its deviation, including the tests in every future release. That makes many requests smaller. Second, every deviation is reviewed after a year: is it still needed, or can the country go back to the template? Many requests come from habit. If the sponsor in the country understands why the template is built the way it is, they can put these requests in context before they reach the architect, more on that in Change management in a global Salesforce rollout.

Metrics per country show whether the template holds

The 80 percent is a guideline, not an exact measurement. Still, the direction is easy to follow with three simple numbers per country:

• Number of approved deviations, split by the five groups in the table. If the group “different business” grows in several countries, it is time to extend the template.
• Country-specific metadata. Flows, record types or page layouts that exist for one country only. The number should be close to zero.
• Test effort per release for the country. If a country needs clearly more test cases than the others, it carries more deviations than the list shows.

Write down the goal before the first country

Before the first country, decide what the goal is and write it down. If it is harmonisation, the guideline for the match and the request path for deviations follow from it. Then keep a list of deviations per country, with reason and approval date. The list should also say what each deviation costs in operation, such as an extra test case in every release. In the steering committee it shows at a glance whether the template holds. How countries take up the template is also a question of change management.