A single-site CAFM is a relatively tidy problem. Multi-site is a different beast. The moment you have two or more campuses, warehouses, or regions using the same system, you face a hard question: what do they share and what do they keep separate? Get that wrong and you either force campuses to duplicate every vendor and spare part, or you break their operational independence. This guide shows how to architect it properly.
The core tension
Multi-site CAFM architecture is a balancing act between two forces:
Centralisation
Shared data, consistent standards, one vendor list, consolidated reporting, central governance.
Site Independence
Operational autonomy, site-specific work orders, local ownership of decisions.
Too much centralisation and each site fights the system to do its job. Too little and you end up with ten disconnected systems wearing one logo. The architecture below is how you get both.
The three-tier organisational model
The pattern I use on multi-site implementations is a three-tier structure: one Common organisation plus one per site. Simple, proven, scales from two sites to twenty.
- Common Organisation, holds shared master data applicable to all sites
- Site A Organisation, holds site-specific transactions and assets
- Site B Organisation, holds site-specific transactions and assets
...add more site organisations as needed.
What belongs in the Common organisation
The Common org is for data that should be standardised across the whole operation. If every site maintains its own version of this data, you get drift, duplication, and reporting pain.
Master Data
- Parts / spare parts master
- Vendors & contractors
- Asset classifications / templates
- Locations hierarchy templates
Operational Standards
- PM templates
- Checklists / task libraries
- SLA definitions
- Service request categories
Codes & Taxonomy
- Failure codes (Problem/Cause/Action)
- Standard work instructions
- Safety procedures / LOTO
Governance
- User roles & permission templates
- Document library (manuals, drawings)
- Workflow / approval templates
The test for "should this be shared?"
Ask: "If this record is different at each site, do we lose reporting capability or standardisation?" If yes, it belongs in Common. If each site legitimately needs its own version (e.g., a specific asset installed at Campus A), it belongs in the site organisation.
What stays site-specific
Transactions always belong to the site where they happened. This is non-negotiable for accurate reporting and operational accountability.
| Transaction Type | Ownership |
|---|---|
| Work Orders | Site-specific |
| Purchase Requests | Site-specific |
| Inventory Transactions | Site-specific |
| Purchase Orders | Site-specific (with shared vendor data) |
| Goods Receipt Notes (GRN) | Site-specific |
| Service Requests | Site-specific |
| Asset Records | Site-specific (using shared asset classifications) |
Data visibility rules
The multi-org structure only works if access rules are clearly enforced:
- Site users see their own site + Common. A Site A supervisor sees Site A transactions + all shared data. They should never see Site B's work orders.
- Cross-site access is explicit. Only enabled for FM Engineers, Management, and IT Administrators who need consolidated visibility.
- Common data is read-only for site users. Technicians at Site A should not be modifying the global vendor list or PM templates.
- Governance roles manage Common. Only designated admin roles can update shared master data.
Consolidated reporting across sites
One of the biggest payoffs of this architecture is the ability to do cross-site reporting without losing site-level integrity:
- Group-level KPI dashboards (all sites rolled up)
- Site comparison reports (Site A vs Site B on SLA compliance)
- Vendor performance across sites
- Asset class reliability (all chillers across the group)
- Consolidated procurement spend
These reports only work because assets at both sites use the same classification, work orders at both sites use the same type framework, and vendors have one unified record. That's what the Common org buys you.
Common multi-site architecture pitfalls
- Duplicating vendors per site. Creates drift and kills consolidated procurement reporting.
- Letting each site define its own work order types. Group KPIs become meaningless.
- Over-restricting site-to-site visibility. Management cannot do their job if they can't see both sites.
- No clear ownership of Common data. Shared data needs a designated custodian or it drifts.
- Treating "Region" or "Zone" as a separate org. Usually an over-complication. Use the location hierarchy instead.
- Building integration to finance at site level. Integrate at group level with site/campus as a dimension.
Scaling the model beyond two sites
The same architecture extends to 5, 10, or 20+ sites without fundamental change. What changes as you scale:
- Governance process for Common data. With 20 sites, master data changes need a formal approval workflow.
- Regional groupings. You may want an intermediate layer (Region → Site) in reporting hierarchies.
- Dedicated master-data owners. Someone owns vendors, someone owns PM templates, someone owns failure codes.
- Stronger access controls. More sites means more people and a bigger attack surface for accidental changes.
Conclusion
Multi-site CAFM architecture is not a technical problem, it's an organisational design problem that technology enables. The three-tier model (Common + one org per site) balances standardisation and autonomy, keeps reporting consolidated without compromising site independence, and scales cleanly as the operation grows.
The single most important decision is what goes into Common. Make that decision deliberately, document it, and resist the temptation to let each site "just customise a bit." That's how multi-site architectures fail, not in one big decision, but in a thousand small compromises.
Written by Muhammad Abbas
Enterprise integration specialist. Architected multi-site CAFM, EAM, and CMMS deployments across universities, utilities, and corporate estates.
Work with me