What breaks when you roll an integration out across multiple locations?

Three structures, three different problems

Before designing anything, establish which of these you actually have, because the engineering diverges sharply.

• One system, many locations. Easiest. The work is correct filtering, permissions and making sure every record carries a reliable location field - which is often optional and therefore sometimes blank.
• Many systems, one company. Acquisitions usually land here. The work is normalization: mapping four different job type schemes to one, and accepting that some comparisons will never be exact.
• Franchise or partial ownership. Hardest, because the constraint is not technical. Who is permitted to see whose numbers, and who owns the data, are questions that have to be answered by people before any pipeline is designed.

Definitions must be forced to agree, and someone has to lose

Rollups are arithmetic on definitions. If one location marks a job complete when the technician leaves and another when the invoice is paid, a combined completion metric is meaningless and worse than having none, because it looks authoritative.

The definitions that most often need forcing: when a job counts as complete, what counts as a lead, at what point revenue is recognized, how cancellations and callbacks are recorded, and what a service area boundary is. Someone has to arbitrate, and it is a leadership decision rather than an engineering one. Every honest multi-location dashboard rests on that decision having been made explicitly.

Shared assets manufacture false attribution

One ad account serving five markets, one call center number on all the trucks, one website with a single contact form. Each shared asset creates records that cannot be assigned to a location without a rule, and the rule is usually a guess - the caller's area code, the geography of the click, the first available dispatcher.

Decide the rule explicitly, write it down, and report the share of records assigned by rule rather than by fact. A location manager will eventually challenge their number, and the useful answer is a documented method with a known ambiguity rate. See marketing intelligence for how that gets reported honestly.

Permissions are part of the model, not a setting

A location manager should see their own operation in detail and comparative context without necessarily seeing another manager's payroll or margin. Ownership sees everything. Regional leadership sees a slice. This structure has to exist in the data model, because retrofitting permissions onto a reporting layer built without them means rebuilding it.

Get the hierarchy - company, region, location, team, individual - defined before the first dashboard is built. It is far cheaper than discovering during rollout that every number in the system is company-wide.