CRM permissions for multiple companies work by combining record-level sharing with field-level restrictions: each business unit owns and edits its own accounts and leads by default, while shared records are opened selectively, at the field rather than record level, to named roles in sibling entities, and group leadership holds aggregate or read-only visibility without inheriting edit rights. Getting there usually means going beyond a role hierarchy and its sharing rules, because that model can only widen access, never shape it selectively between separate brands.
Every group operator eventually types some version of the same query into a search box: how do CRM permissions work across multiple companies? The question usually arrives at a specific moment. Two of your trading companies have discovered they are selling to the same customer, or you have just acquired a competitor whose pipeline cannot be visible to the sales team that used to lose deals to them, and your incumbent CRM offers you a choice between one shared database where everybody sees everything and several separate instances where nobody sees anything. Neither of those is the answer you wanted.
This piece is written for the person who owns that decision, usually a group CEO, FD or commercial director rather than the administrator who will be asked to configure it. The mechanism matters more than the settings, because the mechanism explains why the settings will not get you there.
Executive Summary
Most CRM platforms model permissions around a single company with a single management hierarchy, so visibility flows up one tree and access is granted by widening a locked-down baseline. Groups of companies need visibility that flows sideways and selectively, which the model cannot express natively, so multi-entity groups are pushed into either one shared database with all-or-nothing access or several disconnected ones. The escalation path documented by vendors themselves runs from org-wide defaults through role hierarchies and sharing rules to manual sharing and finally to custom code, and it is that last step where multi-entity groups end up living, at consultancy day rates. UK data protection guidance sharpens the stakes: the Information Commissioner's Office is clear that a controller moving data to itself is not data sharing, which implies that moving customer data between separately incorporated companies in a group generally is. The commercially useful question to ask a vendor is not whether it supports multiple companies, but whether an account can be shared between two brands at field level without either of them being able to see the other's wider pipeline.
How do you set up record-level permissions in a CRM so different business units can only see their own accounts and leads?
Record-level permissions restrict visibility to individual accounts and leads rather than to a category of record, and they are set by combining an ownership rule (each business unit owns its own records by default) with narrow, explicit exceptions for anything genuinely shared. In practice this means starting from a locked-down default per entity, then opening named fields, such as deal value or stage, on specific shared records to specific roles in a sibling brand, rather than opening the sibling's whole pipeline. Most CRM platforms can express the ownership rule easily. Very few can express the field-level exception without custom development, because their sharing rules are built to widen access uniformly rather than to shape it selectively.
Why do CRM permissions break down across multiple companies?
The reason is economic rather than technical. Mainstream CRM platforms are deliberately built to be generic and broadly applicable, because the widest possible market is where the licence revenue is. Steering a product at everyone means fitting no one exactly, and multi-company groups lose out more than most: they are a smaller addressable market, and they buy through a longer, more drawn-out process involving several stakeholders who each own a different piece of the answer. Fine-grained visibility control between brands never wins the roadmap argument against a feature that every single-entity customer will use on day one. That is a rational product decision, and it leaves a real class of buyer unserved.
The consequence is that permission models were designed to answer one question: who, inside this company, should see this record? A group needs to answer a second question that looks similar and behaves completely differently: who, inside one of our companies, should see a record that belongs to another of our companies, and how much of it?
Sharing between two of your own brands is a harder engineering problem than sharing with a customer, and almost no platform treats it as a first-class case.
What does the standard CRM permission model actually assume?
The canonical approach is documented openly by the largest vendor in the category. Salesforce's own help documentation describes organisation-wide defaults as the baseline access users have to records they do not own, with role hierarchies, sharing rules and manual sharing used to open access back up selectively (Salesforce Help, Sharing and Record Access Features). Salesforce's Trailhead training makes the direction of travel explicit: sharing rules can never be stricter than the org-wide default, they only ever grant greater access (Salesforce Trailhead, Define Sharing Rules).
Read that again with a group structure in mind. Access is a ratchet that only turns one way, and the hierarchy that governs it is a single tree. A group commercial director sitting above five managing directors will, by default, inherit access to everything beneath them, which is often exactly what the group wants for reporting and exactly what it does not want for day-to-day pipeline. Split the tree into five branches to stop the inheritance and you have just severed the collaboration that made a single system worth having.
Figure
The escalation ladder in a conventional CRM sharing model
- 01
Lock it all down
Set the organisation-wide default to private, so users see only records they own.
Baseline setting
- 02
Rebuild the org chart
A role hierarchy grants managers access to records owned by everyone below them, in one tree.
Structural
- 03
Write exceptions
Sharing rules re-open access to named roles or groups, and can only widen access, never narrow it.
Configuration
- 04
Share by hand
Where no consistent group of users can be defined, owners share individual records manually.
Manual, per record
- 05
Write code
Where rules and manual sharing are insufficient, access is granted programmatically by developers.
Billable
Each rung is cheaper than the one below it. Multi-entity groups tend to end up on the bottom rung.
In practice, hours get spent inside CRM vendors arguing internally on behalf of customers who need to manage several businesses, or businesses with atypical customer relationships. What those customers are asking for are rarely bolt-ons. They are fundamentals that have to sit in the foundations, and configurable visibility control at a fine-grained level, both within a brand and between brands, is the one that matters most. Most systems manage it within a single brand and do it imperfectly. Between brands it collapses into all-or-nothing.
Three ways to configure visibility between brands
Most groups need some blend of three patterns, and naming them separately makes it easier to ask a vendor for each in turn.
Full separation suits newly acquired entities still mid-integration, or brands that compete for the same customers pre-acquisition. Neither side has any access to the other's records, and the only visibility sits above both, at group level, and even then usually as aggregates rather than named accounts.
A shared account with restricted contact detail suits the far more common case: two brands legitimately selling into the same customer. The account exists once, both entities can see that the account exists and roughly where it stands, but each edits only its own commercial lines and neither sees the other's contacts, notes or attachments in full.
Group-level read-only for the parent suits the FD or group commercial director who needs to know how the group is trading without needing edit rights over any single entity's pipeline. This is the aggregate view: totals and trends, not the ability to reassign a lead or change a stage.
Each of these is a distinct permission shape, and a platform that only offers the two extremes, shared everything or shared nothing, cannot express any of them cleanly.
Who should see what between brands? A worked example
Abstraction hides the problem, so take a specific shape. A group holds five trading companies and roughly 60 CRM licences. Entity A does facilities maintenance, Entity B does electrical contracting, and Entity C was acquired nine months ago from a firm that competed directly with A. A national retail chain buys from both A and B and is being pursued jointly. Here is the access matrix the group actually wants.
| Who | Own entity's pipeline | Sibling entity's pipeline | The shared national account | Entity C, first 12 months |
|---|---|---|---|---|
| Account manager, Entity A | Full edit | No access | Read all, edit own entity's lines | No access |
| Sales director, Entity A | Full edit | Value and stage only, no contacts | Full edit | No access |
| Group commercial director | Full edit | Full edit | Full edit | Totals only |
| Group FD | Aggregates only | Aggregates only | Aggregates only | Aggregates only |
| Account manager, Entity C | No access | No access | No access | Full edit |
Every cell in that grid is a legitimate commercial position. The sales director of Entity A needs to know whether a sibling brand is already quoting a shared customer, and does not need the contact names to find that out. The group FD needs a number and nothing else. The account manager in the newly acquired business needs to be sealed off in both directions while integration and any transitional arrangements run their course.
Now try to express that grid with an org-wide default, a single role hierarchy and a set of rules that can only widen access. You cannot, because the requirement is partial and directional: read the stage but not the contact, edit one entity's lines on a shared record but not the others. Object-level and record-level grants in one tree do not have that vocabulary. So the group commissions a bespoke build, and the permission model becomes a codebase that one contractor understands.
What does bolting this on actually cost?
The direct cost is implementation hours, and it recurs every time the group buys, sells or restructures a company. The indirect cost is larger and shows up in places nobody attributes to permissions.
McKinsey's work on data costs found that where a clear inventory of available data is missing, users can spend between 30 and 40 per cent of their time simply searching for data, and 20 to 30 per cent on cleansing it where robust controls are absent (McKinsey, Reducing data costs without jeopardizing growth). A group whose brands each hold a partial view of a shared customer has manufactured exactly that condition inside a system it already pays for.
Figure
Time lost when data access and controls are weak
30-40%
of data users' time spent searching for data
Where no clear inventory of available data exists
20-30%
of time spent cleansing data
Where robust data controls are not in place
That sits on top of an already thin selling day. Salesforce's 2026 State of Sales research reports that sales representatives spend 60 per cent of their time on non-selling tasks, and that 84 per cent of sales teams without an all-in-one platform intend to consolidate their technology (Salesforce, sales statistics for 2026). Consolidation is the instinct groups reach for, and it is the right instinct. It fails when the consolidated system can only be made safe by keeping brands apart, which is why so many groups end up with an expensive CRM plus a spreadsheet that quietly does the cross-brand work. The same dynamic drives the cost of custom CRM reports: once visibility is bespoke, so is every roll-up built on top of it, and group reporting inherits the bill. It is also where the real cost of CRM licences, implementation and the bill that follows tends to diverge from the number on the original quote.
Does UK data protection law change the answer between brands?
It changes the stakes. The ICO's data sharing code of practice is explicit that the code does not apply to disclosure within the same organisation where the controller is one and the same, because a controller moving data to itself is not data sharing (ICO, Data sharing covered by the code). The corollary matters enormously to groups. Separately incorporated trading companies are usually separate controllers in their own right, so pushing a customer record from Entity A into Entity B is generally a data share between organisations rather than an internal transfer, with a lawful basis, transparency obligations and often a data sharing agreement attached.
The ICO also anticipates precisely the granularity that CRM platforms struggle with. Its guidance on data sharing agreements notes that it may be appropriate to attach permissions to certain data items so that only particular members of staff, or staff in specific roles, may access them (ICO, Data sharing agreements). Separately, the ICO's guidance on data protection by design and by default states that organisations must protect the personal information they store and make sure only those who need to can access it (ICO, Data protection by design and by default).
What should a group ask a vendor instead?
"Do you support multiple companies?" gets a yes from almost everyone, because almost everyone can create a custom field called Entity and filter a report by it. Filters are cosmetic. The questions that separate architecture from decoration are narrower and harder to answer with a slide.
Can a single account be shared between two brands so that each edits only its own commercial lines, while neither can see the other's wider pipeline? Can a lead be routed from one brand to another with a full audit trail, without granting the receiving team standing access to the originating brand's database? Can visibility be granted at field level rather than record level, so a sibling brand sees deal value and stage without seeing contacts? Can a group-level user hold aggregate visibility without inheriting edit rights, given that role hierarchies conventionally grant managers the same access as their subordinates? And when a sixth company joins the group, is that a configuration change or a project?
A vendor whose answer to any of those is "that would be a customisation" has told you where the foundations sit. That is worth knowing before signing, not eighteen months into a rollout, because permission architecture is one of the quieter causes of CRM adoption failure in groups: teams route around a system that either exposes too much or hides too much, and adoption failure of that kind is rarely blamed on the permission model that actually caused it. The broader case for treating this as foundational rather than configurable is set out in our overview of the multi-entity CRM problem.
Frequently Asked Questions
How do you set up record-level permissions in a CRM so different business units can only see their own accounts and leads?
Set each business unit as the default owner of its own accounts and leads, then add narrow exceptions for genuinely shared records: field-level access to value and stage for a sibling brand, full edit rights only for the owning entity, and aggregate-only visibility for group leadership. Most platforms handle the ownership default easily; the field-level exception usually requires custom development.
Can one CRM serve multiple companies without staff seeing each other's data?
Yes in principle, and the difficulty depends entirely on whether visibility control is architectural or configured after the fact. Conventional models start from an organisation-wide default and widen access with rules that, as Salesforce's documentation confirms, can only grant more access rather than less, which makes partial cross-brand visibility awkward to express without custom development.
What is the difference between role-based and record-level CRM permissions?
Role-based permissions determine what a user can do with a type of record, such as creating or deleting opportunities. Record-level permissions determine which individual records that user can see and edit. Groups of companies typically need both, plus field-level control, because a sibling brand may legitimately need a deal's value and stage while having no business seeing its contacts.
Is sharing customer data between companies in the same group a data share under UK law?
Often yes. The ICO's data sharing code of practice states that moving data within the same organisation, where the controller is one and the same, is not data sharing. Separately incorporated companies in a group are commonly separate controllers, so transfers between them usually fall within the scope of the code and need a lawful basis and appropriate documentation. Controllership is a legal judgement in each case.
Why do multi-entity permission requirements end up as custom development?
Because the underlying model assumes one company with one management hierarchy. Vendor documentation sets out an escalation path from organisation-wide defaults through role hierarchies, sharing rules and manual sharing to programmatic sharing written by developers. Requirements that are partial and directional between brands generally cannot be met by the configuration rungs, so they land on the code rung.
Should a group run a separate CRM instance for each company instead?
Separate instances solve isolation and destroy collaboration, which is usually the wrong trade for a group whose brands sell to overlapping customers. It also fragments reporting: Salesforce's 2026 State of Sales research found 84 per cent of sales teams without an all-in-one platform plan to consolidate their technology, and consolidation only pays if the consolidated system can keep brands apart selectively rather than absolutely.