Five Ways to Enhance Collaboration Between Tenants

It’s all About Collaboration

If you’ve ever read any Microsoft 365 marketing material, you’ve no doubt seen the word “collaboration” appear countless times. Making it easier for people to work together is one of the core benefits of Microsoft 365. From co-authoring documents in SharePoint Online to Teams chat and meetings, many aspects of Microsoft 365 support collaboration between users.

Extending collaboration to external organizations is a relatively straightforward process. However, some organizations may choose to limit the levels of interaction available with external organizations based on privacy, compliance, or security concerns.

While most organizations operate a single Microsoft 365 tenant, there are cases, such as mergers, acquisitions, and complex corporate structures where multiple tenants need to work very closely together. In this article, I explain five ways to make the cross-tenant collaboration experience easier for end users and when to use each.

Exchange Online Remote Domains

Exchange Online remote domains is a topic that tenant admins recognize as a critical part of a healthy Exchange Hybrid configuration. Remote domains register an external domain with custom settings for how to handle emails sent to that domain. Out of the box, a default remote domain is available with settings for any domain not specifically registered. Custom remote domains take precedence over the settings for the default remote domain.

Several controls exist for remote domains. In a cross-tenant scenario, the email reply types configuration (Figure 1) is particularly useful.

Email reply types for a remote domain control three aspects of mail flow between Exchange Online and an external domain:

1. Enabling internal out-of-office replies allows recipients in the remote domain to receive the internal copy of a user out-of-office message. The text of an internal reply is often different and less formal than the response sent to external correspondents and can contain organization-specific information that you don’t want to send externally.
2. Enabling or disabling automatic replies is useful if your organization doesn’t currently allow external automatic replies. The automatic reply settings are enabled only for the remote domain in this case while being switched off in the default remote domain.
3. Enabling automatic forwarding is a key configuration for organizations approaching a tenant-to-tenant migration. In this scenario, users often have accounts in both tenants and need to receive mail from both organizations before the mail domain is transferred. Automatic forwarding is disabled by default in the Exchange Online outbound anti-spam policy so enabling forwarding for the remote domain means that the anti-spam policy must be modified to prevent blocking of forwarded email. Additionally, it’s generally not recommended to permit external forwarding to untrusted domains, so the default remote domain setting should be set to block automatic forwarding.

Disabling automatic replies isn’t generally something that enhances user experience, but allowing internal out-of-office replies and automatic forwarding to specific trusted domains are small things that support collaboration between two separate tenants.

Custom remote domain configurations can be particularly useful when an organization has more than one tenant. In this case, having users receive internal out-of-office messages can help users in the organization to get better visibility of their colleague’s status when away.

Calendar and Availability Sharing

Another Exchange Online feature that admins may already be familiar with, calendar and availability (Free/Busy) sharing are great ways to bring tenants close together. When organizations work closely together, being able to view the availability of users across tenant boundaries can cut down on user frustration (if users know how to use the Outlook scheduling assistant function).

Sharing calendar information is broken into two different areas. For availability information (Free/Busy) organization relationships control the level of information available and optionally, a specific group of users who can be viewed by the external domain (Figure 2).

For more fully featured sharing, sharing policies allow users to share their full calendar (and optionally, contacts) with users in the external domain. As shown in Figure 3, this feature is useful for teams hosted in different tenants that work closely together and need more information about user schedules. Unlike organization relationships, enabling this policy does not immediately grant any access because users must first share their calendar with the intended recipient from the external tenant.

One thing to note about calendar and availability sharing is that while users can see availability for room and equipment mailboxes, there isn’t currently a way to share room lists across tenants.

Allowing calendar sharing and availability visibility tenant-wide isn’t something you would generally do for a partner domain. I don’t know many companies who would be happy with an external organization being able to browse calendar details. In scenarios where multiple tenants belong to one organization, the additional level of visibility provided by calendar and availability sharing can make for a better, more coherent user experience across tenant boundaries.

Microsoft Entra ID Guest Accounts

Guest accounts are a great feature for collaborating with external users. With guest accounts, external users are invited into your organization. When an invited user accepts their invitation, Entra ID creates a guest account for them (as shown in Figure 4).

The account has a user type of Guest, differentiating it from regular member accounts. With a guest account, authentication occurs in the user’s home tenant and authorization to access resources is controlled by the tenant hosting the guest account. For a more detailed explanation of how guest accounts work, read explaining Entra ID external identities.

Basic guest user invitation settings in the external collaboration section of the Microsoft Entra admin center control who can send invitations to external guests and from which domains guests can be invited. This is an important consideration when planning the guest account strategy for your tenant. While some organizations make guest invitations available to any external individual, a strong case exists to limit the use of guest accounts to known partner organizations.

There’s no “correct” answer for managing guest invitations in a tenant. However, a common practice is to allow invitations to specific whitelisted, preapproved domains. In this scenario, a level of control applies to allow users to invite guests while preventing excessive guest account creation and sprawl.

While guest accounts can greatly help organizations work together, when you plan a cross-tenant migration, they may cause more trouble than they’re worth and should be avoided. If you already have a proliferation of guest accounts and a looming migration project, it is possible to convert guest users to members while maintaining user collaboration, however, I recommend avoiding the problem from the outset if possible.

Cross-Tenant Access Policies and Multi-Tenant Organizations

Expanding on the idea of guest user invitations, cross-tenant access defines the access level allowed for specific partner tenants. Cross-tenant access includes individual configurations for B2B collaboration (guest access) and B2B Direct Connect (currently only supporting Teams Shared Channels).

At a high level, cross-tenant access policies are configured for tenants to customize the level of collaboration unique to that specific tenant. Each organization you create is then configured to allow or disallow the following elements of collaboration:

• Guest user invitations, both inbound and outbound
• Direct Connect access, both inbound and outbound
• Restrict who can be invited as a guest to a security group
• Restrict who can use direct connect to a security group
• Restrict which applications are available to guest users
• Synchronize users between tenants
• Implicitly trust MFA, device compliance, and device identity from an external tenant

For full details on how to create and use cross-tenant access policies, check out this article.

Cross-tenant access can be extremely useful when two organizations work closely together. In many cases, Shared Channels through B2B Direct Connect can replace the need to manage guest accounts.

While cross-tenant access is great for partner organizations, the recently launched multi-tenant organization (MTO) preview feature expands collaboration possibilities for organizations with multiple tenants. Using cross-tenant access policies in the back end, MTOs effectively synchronize users between tenants to build a unified global address list and enhance the Teams experience (the Teams 2.1 client only). For a full analysis of the value of MTOs, read this article.

When it comes to when you should use MTOs, the key use case here is organizations that have multiple tenants. MTOs are not designed for partner organizations and I don’t recommend using MTOs where a tenant is not within your direct organization or group. As for tenant-to-tenant migrations, while MTOs seem like a logical way to achieve enhanced collaboration from an early stage prior to migration, many caveats exist that need careful consideration. Like guest accounts, accounts created through an MTO can gather permissions over time (such as group memberships or file-level permissions), and if you don’t have a solid plan to manage this (such as auditing or controlling the access granted to each account), removing the accounts at cutover time could prove problematic for both admins and end users, leading to migrating users not having the same file/group access they had prior to migration. As with any preview feature, I caution against using MTOs in production tenants as experiences may vary until the feature has matured.

SharePoint External Sharing

SharePoint (and by extension OneDrive) allows users to share files (and folders) with internal and external users for live collaboration and as a robust replacement for email attachments. I’ve seen many organizations shy away from external sharing, believing (incorrectly) that it is less secure than their current process, which usually involves sending email attachments. One key benefit of using external sharing over traditional attachments is that access is controlled by your tenant and can be modified or revoked at any time.

Like guest accounts, SharePoint external sharing can be controlled to restrict who can share, who they can share with, and the level of access that is granted by default. As shown in Figure 5, a typical conservative sharing policy allows sharing with existing guest users and is limited to two partner domains. Depending on the organization, the policy for both OneDrive and SharePoint can be tailored to meet both the collaboration and security/risk requirements of the business.

Sharing settings can also be set on a per-site basis. For example, individual sites containing sensitive information can be restricted from external sharing while others follow the tenant defaults (a site cannot be less restrictive than the tenant settings).

In addition to sharing policies, external sharing in SharePoint is supported by Data-Loss Prevention (DLP) policies and any shared documents can be further protected through Sensitivity Labels. Sensitivity labels for containers also support the configuration of the site-sharing policy, meaning that classifying a site with a sensitivity label enforces a tenant-set sharing policy automatically.

External sharing can be used with partners, customers, and other tenants. There is no bad use case for external sharing, particularly compared to something like email attachments. There are, however, sometimes when external sharing may not be the most efficient way to collaborate. For example, when organizations work together on multiple files, guest access to Teams gives a more fully featured experience. Shared channels through B2B direct connect are also a good contender in this case, where the set of data is contained in a single channel of a Team. It’s also worth keeping in mind, as with most of the good stuff in Microsoft 365, that even simple sharing from SharePoint can present a challenge in tenant-to-tenant migrations.

To learn more about modern compliance for SharePoint sites and information architecture, check out this article.

Summary

In this article, I explained five ways of enhancing the collaboration experience between Microsoft 365 tenants. A growing list of features exists to help organizations work together more efficiently and it’s important to know when to use each feature and when to avoid them. Whatever you decide to implement, the key to a successful deployment is communication. Make sure end users understand what is in place and communicate regularly during deployments to make sure you bring the benefits to them.