Most CRMs are built for a company. Not a group of them.
TL;DR: A CRM for multiple companies, often called a multi-entity CRM, is a system built to run several trading companies, brands or subsidiaries through one platform. It gives each entity its own records and permissions while still sharing leads, collaborating on shared accounts and rolling reporting up to group level.
Most mainstream CRMs struggle with multi-entity setups because they are built around a single company record and a single permission hierarchy. Groups typically work around this with separate instances stitched together by spreadsheets, duplicated records tagged by brand, or heavyweight custom development bolted onto a generic platform.
None of those workarounds gives a group shared lead routing, cross-entity account collaboration and roll-up reporting at the same time, because the underlying data model was never designed to hold more than one company in the first place. Holding companies, groups of trading entities and owner-operators running several brands all need a proper multi-entity CRM for the same reason: standard CRM for multiple companies assumes a single company, then treats every additional entity as an exception to be configured around, which is slow, expensive and never quite finished.
That sounds like a small distinction until you try to run four trading entities through one system and discover that the thing you need most, deciding precisely who can see what, across brands as well as within them, is the thing the platform handles worst.
Can one CRM run several companies?
Mainstream CRMs struggle with multi-entity setups because permission and visibility control at a fine-grained level, both inside a brand and between brands, was never designed into the data model. The functionality a multi-entity group needs is not a bolt-on. Bolt it on afterwards and you get the situation most groups are actually in: an all-or-nothing setup, where a user either sees everything across every company or nothing outside their own.
Neither answer is the one anybody wanted. What a group actually wants is four things working together: shared lead routing so an enquiry lands with the right brand without manual triage, cross-entity account collaboration so a shared client can be worked by two brands at once, record-level segregation so a sensitive account stays visible to only the entity that owns it, and roll-up reporting so the group board sees consolidated numbers without someone rebuilding a spreadsheet every month. Most platforms deliver at most two of the four natively; the rest gets improvised. Common workarounds include running a separate instance per subsidiary and reconciling data by hand, tagging every record with a brand field inside one shared instance and trusting staff not to open the wrong one, or paying for custom development to simulate segregation that the platform does not enforce. Each of those is explored in more detail in the record-level permissions and cross-brand lead-sharing articles below.
Why doesn't mainstream CRM handle multiple companies natively?
The gap exists for economic reasons, not because vendors overlooked it. Mainstream platforms serve a market where multi-entity structure is the exception, so it never becomes a foundation-level design requirement.
Mainstream CRMs are designed to be generic and broadly applicable, and steering at the widest possible audience means fitting no particular audience very well. Multi-entity groups are a smaller addressable market with a longer, more drawn-out buying process. Their fundamentals never win the roadmap argument against features that serve the larger, faster-closing segment.
So the need gets met by implementation instead, configuration, custom objects, elaborate automation, which is why serving a group properly on a general-purpose platform runs into millions of pounds of implementation hours. The real cost of that approach, and why it keeps recurring long after go-live, is set out in the true cost of ownership for multi-entity CRM.
What breaks when you use one instance per entity?
Groups converge on one of three architectures: separate instances per entity, one generic CRM bent into shape with custom fields and workflow, or one system designed from the ground up for multiple entities. The first two both fail in predictable ways as the group grows, which is why most groups end up trying both before landing on the third. Most groups move through these setups in roughly this order, feeling the pain of the previous one before adopting the next:
Figure
Three ways groups structure their CRM
| Dimension | Separate instances | One shared instance, no controls |
|---|---|---|
| Cross-brand visibility | None; each company is an island | Everything, to everyone, always |
| Shared leads and accounts | Manual, via spreadsheet or email | Easy, but with no protection |
| Group-level reporting | Rebuilt by hand each time | Native, but noisy and unfiltered |
| Where most groups end up | Outgrown within 1-2 years | Abandoned after a data leak or client complaint |
Illustrative comparison, not a survey finding.
Source: Atrium desk analysis
The third option, fine-grained permissions built into the data model from the start, is the one that lets brands share leads and collaborate on shared accounts while still locking down what needs protecting. It is also the option mainstream platforms are least likely to offer natively, for the economic reasons above. Where single-entity assumptions surface first inside a platform that was never built for a group is covered in single-entity CRM assumptions, and what group-level reporting actually requires once several entities share a system is covered in rolling up reporting across a group. What fine-grained record-level permissions and cross-brand lead sharing look like in practice are covered in the two linked spokes.
What this hub covers
The articles below work through the specifics: what fine-grained permissions actually mean in practice (record-level permissions), where single-entity assumptions surface first (single-entity CRM assumptions), what cross-brand lead-sharing requires (cross-brand lead sharing), what it actually costs to bolt this on after the fact (true cost of ownership), and what group-level reporting actually requires once several entities share a system (rolling up reporting across a group).
Frequently asked questions
Can I use one CRM for multiple companies?
Yes, provided the platform supports record-level permissions between entities, not just within one. Without that, a holding company is left choosing between full visibility across every subsidiary or none at all, which is rarely what the structure of the group actually requires.
What is the difference between multi-entity and multi-currency CRM?
Multi-currency support means a CRM can record deals and report revenue in more than one currency. Multi-entity support means the platform can separate and share records, permissions and reporting across genuinely distinct legal or trading entities. A CRM can handle multiple currencies while still assuming a single company underneath; the two problems are unrelated and solving one does not solve the other.
Do I need separate CRM instances for each subsidiary?
Not necessarily. Separate instances avoid cross-brand visibility problems but block lead sharing, cross-entity collaboration and group-level reporting, each of which then has to be rebuilt by hand. A single system with record-level permissions between entities can deliver the separation without losing the ability to share and report across the group.
Why do most mainstream CRMs struggle with multi-entity setups, and what workarounds are companies currently using?
Mainstream CRMs are built around a single-company data model, so multi-entity groups typically work around the gap with separate instances, brand-tagged records in one shared instance, or custom development, none of which delivers shared leads, cross-entity collaboration, segregation and group reporting together.
What does record-level permission mean in a multi-entity CRM? Record-level permission means access is controlled per record, such as a specific lead, account or opportunity, rather than per module or per user role. In a group of trading entities this is what allows a shared account to be visible to two brands while a sensitive client stays visible to only one.
Does an owner-operator with several brands need this, or just a single CRM with custom fields? Custom fields and business units can simulate separation for a while, but they do not enforce it. An owner-operator running several brands through one instance without genuine record-level control is relying on staff discipline rather than the system itself to keep the wrong people out of the wrong accounts.
Why is this so expensive to fix after the fact? Because permission logic that was never designed into the data model has to be simulated afterwards through custom objects, workflow rules and layered automation, each of which has to be maintained and re-tested as the group changes shape. That ongoing configuration burden, not a one-off licence fee, is where the real cost of ownership sits.