What changes about a software project when we run multiple locations?
Multi-location introduces four things a single-location build never handles: data isolation between branches, rollup reporting that has to reconcile differing local practices, per-location configuration, and permissions that follow a hierarchy. Retrofitting those later usually means restructuring the data model, so decide up front whether locations are a filter or a first-class concept.
Location as a filter versus location as a structure
The cheap version treats location as a column you filter on. It works until two branches need different rules, or until you acquire a company whose data does not fit your categories.
The structural version treats location as part of identity: a job belongs to a location, a user has a scope, a configuration is resolved per location with a corporate default. It costs more up front and it is close to impossible to add cleanly afterward, because every existing record has to be reinterpreted.
The four requirements that appear with the second location
- Isolation. A manager in one market should not see another market's customers, and the enforcement has to be in the data layer rather than in the interface.
- Rollup with differing practice. One branch marks jobs complete at the door, another at invoicing. Summing them is arithmetically simple and analytically wrong until you normalize the definition.
- Per-location configuration. Pricing tiers, service areas, business hours, tax handling, and which lead sources exist locally.
- Hierarchical permissions. Corporate sees everything, regional sees a group, branch sees one. Plus the awkward case of a person who spans two branches, which every real business eventually has.
The reporting problem nobody warns you about
Rollup reporting across locations fails for a reason that has nothing to do with software: the underlying practices differ. Two branches using the same field to mean different things produce a total that is technically correct and practically useless.
Before building the rollup, audit how each location actually uses each field you intend to aggregate. Where they differ you have two choices — standardize the practice, or map locally and normalize centrally. Both are legitimate. Pretending the difference does not exist is not, and it is the fastest way to lose leadership's trust in revenue reporting across a group.
Acquisitions make all of this immediate
Groups that grow by acquisition inherit different operational platforms, different chart-of-account structures and different definitions of a completed job. The integration layer, not the operational platform, is where those get reconciled.
That is the practical argument for keeping cross-location logic in a neutral layer rather than inside one platform's configuration: when the fifth company joins, you add an adapter instead of a migration. It is also why briefs written per organizational level tend to work better than one shared dashboard — a branch manager and an owner need different aggregations of the same reconciled data, and multi-location operators usually need both at once.
Topics: multi-location · scoping · permissions · reporting
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.