ChatGPT
Claude
Google AI
Copilot
A country closes its books on a Thursday. The global template assumes Friday, and it assumes one tax treatment. The weekend cutover puts every country on that page. By Tuesday the finance lead is invoicing from a spreadsheet, because the shared layout will not produce a document their customer can pay. The country manager opens the one report they have opened every Monday for three years. The total does not match last month. Training, the week before, was a slide of the global page, held while the invoice path was still a mock. People sat through it and went back to the process that gets them paid. They were right to.
Forty countries do not invoice the same way, and they do not close the month on the same day. A rollout that switches them onto one page layout in a weekend will produce shadow spreadsheets by Tuesday. Change management here is a calendar and a local owner. A town hall does not invoice.
The template holds only what must match
The shared template holds the objects and the fields that must mean the same thing everywhere. The account. The opportunity stages you truly share, which is a shorter list than the stages a single country invented. The case fields a global queue will read without a local decoder. If a global person cannot act on a field, it is not a global field, however often a workshop asked for it "just in case."
Local configuration holds tax, invoice format, language, and the approval the country manager is accountable for. If a field exists only so one country can get paid, it does not need to be identical everywhere else. Forcing it identical is how the template fills with optional fields nobody can explain, and how a required field in one country becomes a meaningless picklist in another. The person in the second country then puts any value in it to save the record, and your global report is built on that fiction.
Write the line down before the template grows. Shared: the object, the field, the definition, the reason a global queue or a global forecast needs it. Local: tax, document format, the approval chain, the language of the page, the dispatch constraint that only makes sense in that city. A field with no reason in the shared column goes back to the country. That refusal is the template staying usable. An architecture practice that cannot refuse will ship a page no country can finish a job on.
Sequence the countries. The release train is a list with three columns: what ships this month, what waits, and what is being removed. A country joins when its cutover list is ready, not when a steering slide says the quarter is the global go-live. Putting a country on the train before the invoice path works is how you schedule the spreadsheet. Taking a country off the train, because the list is not ready, is a successful decision. Announce it as a decision. Do not hide it inside a status of amber.
Shape the local work, keep the shared object
Salesforce describes the field product in full: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." Shape is the point of that sentence. A hub that pretends a dispatch model in one city is the dispatch model in every city will be bypassed by the people who still have to arrive on site. Travel rules, languages on the mobile page, and the way a break-fix is classified can differ. The work order object should not. Leave the local constraint in local configuration. Put the shared object, and the fields a global queue must read, in the template.
The same split applies to any cloud you are rolling. Marketing can keep a local campaign calendar. The lifecycle field that both sales and marketing report has one definition, or the global forecast is several forecasts wearing one name. Service can keep local entitlement rules where the contract truly differs. The case fields a follow-the-sun queue reads have to mean the same thing at 9am in each office that touches the case. If they do not, the queue will re-ask the customer, and the customer will notice the handoff.
The cutover list is short on purpose
Data. Which records move, which stay in the old path, and how you will know a record landed once. Once matters. A retry that creates a second invoice, or a second account, is not a successful load. Agree the identifier you will match on, the count you expect, and a sample a local person will open and recognise. "The job went green" is not that sample. The sample is ten invoices, or ten accounts, opened by the person who would notice a wrong tax code.
Access. Who can work in the new org on Monday morning, by name or by role, and who still needs the old path for the work you have not rebuilt. Build that access before Friday. A shared administrator login for the whole country is not access. It is a way to lose the audit of who changed a record, and it will be the login people keep using after you meant them to stop. Profiles and permission sets are ordinary access design on this list. They are not a retirement programme, and they are not finished because a slide said the country is live.
The report. The one report the country manager actually opens. Find it in the first week by sitting with them, not by asking for a requirements catalogue. Watch which file they open before they will talk about the month. That file is the report, even if it is ugly, even if it lives outside the CRM today. Rebuild that view, with the same grain and the same filters they trust, or the rollout is wrong whatever the project dashboard says. A catalogue of forty reports is how you miss the one that matters. You can add the other thirty-nine later, on the train, after this one matches.
A country is done when those three are checked on an agreed sample. Not when training attendance was high. Not when a banner said go-live. The sample is signed by the local owner and the country manager, with the differences written down. Differences are defects. They go on the train. They do not become a separate change-management workstream with its own poster, because a poster will not fix a tax total.
| Cutover line | Ready looks like | A false done |
|---|---|---|
| Data | Counts match, and a local person recognises a sample | The load job reported success |
| Access | Named people can do Monday's job, and the old path is explicit where you still need it | One shared login for the country |
| The report | The country manager opens it and trusts the total | A new dashboard nobody asked for |
| Invoice path | A real invoice can be produced and paid | A mock shown in training |
| Local refusal | The owner can send a change back | Every request in the template is accepted |
Names change. Invoicing does not
Data 360 help records a rebrand, not a new operating model: "As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged." Use the current name in the template so countries are not integrating to a label that has moved. Do not make the rename the rollout. A documentation change is not a reason to retitle every local process in the same week, and it is not a reason to move a country that is not ready. Leave the rename off the cutover list. The list is data, access, and the report.
Product names will move again. The train does not restart when they do. You change the label in the template, you tell the local owners in the note that already goes out with the release, and you leave their invoice path alone. A rename workshop in every country is how a calendar fills with activity that does not get anyone paid.
Training after the page exists
The local owner can refuse a change that breaks invoicing. Give them a seat on the train, with the authority to say a release waits. A travelling steering committee that outvotes them will win the meeting and lose the month-end. The owner is in the country. They know which approval is legally theirs. Write that veto down so a project manager under a date does not have to be brave in the moment. The veto is the design.
Training is a session on the pages that country will use, held after those pages exist, including the invoice path. Use their records. Produce one invoice in the room, or watch them produce it. A session on a global slide, held while that path is still a mock, teaches people to wait you out. The old process still gets them paid, and they will keep it until the new one does. Attendance is not adoption. The test is the invoice, and the report, on the Monday after.
On that Monday the owner opens the report with the country manager. Differences against the sample are defects on the train, with a name and a date. If the manager goes back to the spreadsheet, say so in the note. Do not call the country live. The next country's turn does not start by ignoring this one. A train that only adds countries, and never goes back to fix the report, is a weekend cutover stretched over a year.
Cheap, before a country joins: waiting, cutting a field out of the template, sitting with the manager to find the report. None of that needs a cutover.
Expensive, after the spreadsheet has a month of invoices in it: bringing those invoices back, explaining which total was real, and asking a finance lead to trust the org they have already worked around. That reconciliation is the cost of the weekend you saved. Sequence the countries so you pay it for one country, learn the defect, and do not repeat it for the next ten.
The pages only count as adopted when the work happens on them, which is the test in how a large team should judge adoption. A login on the Monday after go-live is not the report matching. Train after the page exists, then watch the report, not the attendance sheet.
