Hosting multiple subsidiaries or business units in Microsoft 365
Like what you see??
"Ask Sympraxis" is a bi-weekly webinar series, where we discuss an array of topics and answer your submitted questions. Join us by downloading our recurring calendar event. You can also join us directly in the meeting without downloading the event.
See a listing of Ask Sympraxis episodes by topic covered: Topic List, Series List, or a full listing Archive
In this session we talked about how organizational complexity and Microsoft 365. At some point, managing all the different subsidiaries or business units in Microsoft 365 becomes difficult. We talked about our approaches to make all this work.
Organizational Models
We mainly see two different models at play here. The first being, a parent company that has a pool of shared services that all the subsidiaries avail themselves like HR or Finance. These subsidiaries really operate like business units. The second model is where different subsidiaries operate independently and have their own M365 tenant but need to work with the parent company.
This is less about the ownership structure strictly from an accounting point of view and more of an operational structure. Where do certain operations like HR take place? At the parent or autonomously at the subs.
We’ve been asked
“We have multiple subsidiaries with different/autonomous operations but common ownership - can I have them in the same tenant?”
“What if multiple subsidiaries share a common set of shared services?”
Shared access means either you’re over permissioned a lot or you’re creating separate sites for the same function and then even need to audience target content. You would need HR-Parent, HR-Subsidiary1, HR-Subsidiary2. This gets very complicated very quickly.
If you do keep everything in the same tenant and you do want to only let subsidiary A see finance here or finance there, you can do this with permission settings. However, you are taking on a burden to ensure every site or library is permissioned correctly, as well as managing the membership of those two groups.
Key Considerations:
- Permissions
- Multiple domains in the same tenant
- Exchange Online can handle this but SharePoint can only have one root (e.g. mycompany.sharepoint.com
- AAD Premium
- If you want to use dynamic AAD groups you will need AAD Premium for at least the creating user
- Global Issues (data sovereignty, multi-geo, performance)
- Is subsidiaries are international
- Issues regarding data sovereignty. Where can the data live, can it cross borders
- User profile data: with multi-geo enabled all user profile data is copied across all geos. It was intended for replication of data not to enforce data sovereignty
- Performance should not be an issue except if you have an Azure instance in a specific geo. (e.g. using an Azure instance in Asia from the US.) There is little impact on SharePoint or other M365 services.
Resources
- Microsoft Docs on Microsoft Entra ID (formerly Azure Active Directory)
- Todd’s blog post on adding users to dynamic groups in AAD
- Microsoft article on audience targeting (in navigation, news & files, etc.)
Do you have any questions for us? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.