Guest Access Series: Inviting a Specific Domain into a Specific Team — Power Apps to Make it Work

One app to rule them all

A Power App to Orchestrate it all

As we stated earlier, when a team’s been configured to not allow guests to be invited, but you want to control how it’s done, you’ll need to provide another manner to do so.

Power App to invite a Guest into the Team

‘Settings’ screen for the created Power App

There are a couple things to call out here to describe how all of our previous work is leveraged, along with additional items that make the entire solution work as a whole. Of specific note is that this app is expected to be embedded inside a team.

Guests in Team Gallery

This is a gallery whose Items property is a collection called guestUsers. This collection is valued when the app starts with the following formula. Note the filter. We use ‘#EXT#’ because that’s what can be used to identify a guest in the directory.

ClearCollect(guestUsers, Filter(Office365Groups.ListGroupMembers(groupId).value,"#EXT#" in userPrincipalName))

When a guest’s information is displayed in the gallery, selecting a user will display their details in the Guest Details section.

Email Address Validation

While the fields on the main screen are self-explanatory, we use formulas in the screen to display the validation message as well as enable/disable the check/submit button (grayed out in the image above).

The first validation for the email address is a simple IsMatch(), see below.

IsMatch(txtInviteGuestEmailAddress.Text,Email)

The second validation is against the collection that holds our allowed domains. This collection is valued at the start of the application, and then used as the items for the Allowed Domains List gallery on the settings page we created. We basically parse out the domain portion of the email and look it up against the values in the collection. The result of which sets the validation text to say valid/invalid, as well as enable/disable the submit button.

Right(
        txtInviteGuestEmailAddress.Text,
        Len(txtInviteGuestEmailAddress.Text) - Find(
            "@",
            txtInviteGuestEmailAddress.Text
        )
    ) in colDomains

Invite our Guest

When all the validation passes, and the submit button is enabled, we just call our previously made workflow, passing in the relevant parameters, so send out the invitation, and add them to the team.

InviteGuesttoTeam.Run(
    tenantId,
    teamId,
    groupId,
    txtInviteGuestDisplayName.Text,
    txtInviteGuestEmailAddress.Text,
    txtInviteGuestMessage.Text
)

Teams Context Information

Take note of the settings screen above and the information it shows in addition to the allowed domains. This information is surfaced as this Power App exists inside a Team. When a Power App is rendered inside a team you have access to all of its information. We leverage this information as part of what we can pass to our flows to execute those processes.

Possible Enhancements

With this just being a proof-of-concept, there are a couple different ways where this could be enhanced. A few items that are top-of-mind are:

• Create a client secret key rotation/storage mechanism to facilitate use of secrets without embedding them in a flow, for example, Azure Key Vault.
• You could also leverage a logic app to do the same and then take advantage of Managed Identities.
• The team-contextual information also provides the user type (User Team Role) executing the app (0=Owner, 1=Member, 2=Guest). You could use these values to, for example, if an owner adds a guest, the request goes right through. If a member does, the owner has to approve. The experience for a guest could be just read/view only.
• You could also enhance the app as a mechanism to manage the SPO site’s domain list from here, and have that go through an approval process as well.

There are a lot of options and additional enhancements you can add to this scenario. As you own the interface and process, it can be whatever you like.

In conclusion

This use case came out of a number of discussions with more than a few customers that wanted to have a little bit more governance around their guest-invitation process. They didn’t want anything complex, or “heavy”, but they also didn’t want the wild west when it came to guests coming in. So, consider this scenario a moderate level of governance for guest access.

Use-cases and scenarios of this nature come out of deep strategic and technical discussions with the architects at the Microsoft Technology Centers. Personally, when I see a use-case become, not necessarily a common one, but one that comes up a lot, I think it’s a good thing to share a theoretic solution out to get the creative juices flowing, to see where those discussions can go. Don’t hesitate to reach out to your Microsoft account team if you have some good use-cases related to the above, or any others that you may have in mind, and they can engage us, and we can take the conversations further.

Coming Soon

For a higher-level of governance than what we’re showing here, we can leverage Azure AD Entitlement Management. That’ll be the next set of articles in this series. Keep an eye out for that series coming soon!