Power Platform tenant isolation – Examples of outbound and inbound connections

Power Platform tenant isolation is generally available, and that’s immediately seen in Power Platform governance work. There are a couple of great posts about tenant isolation out there so I’m not going to recap the whole idea behind it but rather focus on what outbound and inbound connections actually mean.

That said, this blog post will show you the difference between inbound and outbound connections in Power Platform tenant isolation, and how allowlists for those connections are used. It’s fundamentally important to understand how inbound and outbound connections and allowlists work so that tenant isolation is set up the right way.

I suggest you get started by reading these articles first:

• Thibault Joubert – Power Platform & Tenant isolation: why everyone should have a look at it?
• Tatu Seppälä – Plugging some serious holes with Power Platform tenant isolation
• Timo Pertilä – Power Platform ja organisaatioiden eristäminen (Tenant Isolation)

Using outbound and inbound connections

Let’s take a look at what we’re doing and where to understand how inbound and outbound connections work. Our starting point is a flow I’ve created as an admin user in our training tenant.

1. I’ve added a Get file metadata action to my flow and created a new connection and a connection reference (solution flow) by signing in with ff.appuser to our sandbox tenant. The sandbox tenant’s Azure AD is the home of ff.appuser, and that tenant is different from the training tenant where I’m building the flow.
2. The Get file content using path uses the same connection and connection reference by ff.appuser as the previous action.
3. The Create file action uses a connection and connection reference of the admin user, which I’m signed in as in the training tenant.

Let’s twist this a bit and word the scenario differently: While signed in to the training tenant and creating a flow as admin, get a file from the sandbox tenant by establishing a connection to the tenant as ff.appuser, and add the file to the training tenant as admin.

Turning on tenant isolation

Now that the flow is created, let’s turn on tenant isolation in PPAC and see what happens. Tenant isolation takes about an hour to kick in for pre-existing flows: “It takes about an hour for the latest tenant isolation policy changes to be assessed against active apps and flows. This change isn’t instantaneous.” Source: Learn.

The thing with tenant isolation is that when it’s turned on it blocks both outbound and inbound connections unless we create what are called allowlists. It’s these allowlists that let us set whether we want to allow outbound or inbound connections or both.

Now that tenant isolation is on and we’ve waited a while, it’s time to run the flow. We can see that tenant isolation kicks in and produces an error for the connection that was made with the ff.appuser account to access the user’s OneDrive for Business in the external sandbox tenant.

Creating an allowlist for outbound connections

Since we want to get a file from the external sandbox tenant, what we need to do is create an allowlist (tenant rule) for outbound connections. A wildcard * can be used to allow outbound connections to all tenants. One thing I realized was that a wildcard can’t be used for two separate allowlists for inbound and outbound connections. Out of all our allowlists, only one can have a wildcard. After waiting a while, we can run the flow since tenant isolation now only applies to inbound connections.

Creating an inbound connection from the external sandbox tenant

Let’s see what happens when I create the flow in the external sandbox tenant. I’ve created it as ff.appuser but when creating a connection and a connection reference to OneDrive for Business by using the training tenant’s admin’s credentials, we get an error. It’s not the most descriptive error I’ve seen but enough for our use case.

So what exactly is it that we’re doing? Well, we’re essentially trying to establish an outbound connection from the external sandbox tenant to the training tenant, and from the training tenant’s perspective we’re creating an inbound connection to the training tenant. An outbound connection for one tenant is an inbound connection for another. Since inbound connections were not allowlisted in the training tenant, we can’t create a connection from the external sandbox tenant to access OneDrive for Business in the training tenant.

Creating an allowlist for inbound connections

Time to create an allowlist for inbound connections. Like I previously mentioned, the wildcard * can’t be used for the inbound allowlist since it’s already being used in the outbound allowlist. This means that we have to create the inbound allowlist by punching in the tenant ID of the external sandbox tenant.

When the allowlist for inbound connections has been created and we’ve waited a short while, we can try to create the flow in the external sandbox tenant. As the allowlist is in place, we’re able to create create the flow in the external sandbox tenant and pull the file from the training tenant by creating a connection and a connection reference to OneDrive for Business as the training tenant’s admin.

And there we have it! A short show-and-tell of inbound and outbound connections. An outbound connection for one tenant is an inbound connection for another. Should you block or allow inbound and/or outbound connections is completely up to you! The requirements differ between companies so there’s no right or wrong here.