An O365 Group Request App

Reading Time: 4 minutes

This is part 1 of what I anticipate will be a 3-part blog series on building an automated request process for an O365 Group. I say this because I haven’t yet built the components for parts 2 and 3 but wanted to blog this multi-step solution as it was being built. A little risky perhaps but far more interesting and real-world. 🙂

• Part 1 – An O365 Group Request App (this post)
• Part 2 – An O365 Group Request Flow (future)
• Part 3 – An O365 Group Request Provisioned Site (future)

In my last blog, O365 Groups: Are you in control?, I talked about some hot zones for O365 groups from a governance perspective. One of the points I discussed was controlling how group creation was controlled in your organization.

There are 3 options available ranging from least-governed and customizable to most:

OPTION 1: Allow end-users to create groups thru available endpoints in the O365 UI. (Outlook, Planner, SharePoint)

OPTION 2: Limit the creation of who can create groups to a specific Azure AD group by Azure AD configuration settings.

OPTION 3: Automate the request and provisioning process.

This post is about option 3.  I believe this option is what most medium to large-scale enterprise organizations will require for their environments as it allows for some governance (and customization) to be integrated into the process.

This solution will use these services:

PowerApps  |  Flow  |  Azure Function  |  PowerShell (PnP Remote Provisioning)

Here are the high-level workflow steps:

1. End user requests a new O365 Group by filling out/submitting a PowerApps Group Request form to the O365 Group approval person/committee.
2. The Group Request is reviewed and approved/rejected. This will update the request status to either ‘approved’ or ‘rejected’.
3. Flow picks up approved Group Requests and invokes an Azure Function.
4. The Azure Function will take the information from the Group Request and provision an O365 Group (and Team site) using PnP remote provisioning in PowerShell.
   • Note: This is where you can optionally provision customizations in your group/site.  For example: site columns, content types, information management policies can be provisioned to allow for retention on library content.
5. Once provisioned, the Group Request status is set to ‘complete’ and an email notification is sent to both the O365 Group approval committee and the original requestor with the URL to the new group.
6. Process complete.

Sounds simple enough. Let’s dig into the details. 🙂

In the remainder of this post I’ll cover off part 1 of the solution which is steps 1 and 2 above.

---

STEP 1: What information do we need from the requestor? In the PowerApps form we will collect all information required to create the group. When we look at the required properties filled out thru the UI (shown below) this includes: group name, group description, privacy, language, and subscribe new members to conversations in their inbox.

 

STEP 2: Create a custom SharePoint list called ‘Group Requests‘ based on the columns above. I am simplifying this process by assuming all groups will be created with ‘English (United States)’ set as the Language. The columns highlighted below are what will be used to provision the group.

STEP 3: Create a new PowerApps app to be used by staff in your organization to request a new O365 group. The app will use the ‘Group Requests‘ SharePoint list created above as the data connection and each request will populate an item in that list.

Disclaimer: I literally learned how to use PowerApps 2 hours ago so this form is not production-ready but does demonstrate the basic functionality required to populate the SharePoint list. This also speaks to how intuitive and easy-to-use the PowerApps service is.

STEP 4: Within the app create 4 forms: Browse/Detail/Edit/Approve.

Edit form: Add the Group Request (the status is not visible and will default to ‘Requested’)

Detail form: Display the Group Request

Detail Approve form: only an Administrator can see the ‘Review Request’ button.

Approve form: All fields are updateable, including the status. For example, the Approver may want to change the name if it does not comply to corporate standards, etc. If the request is approved, the status will be changed to ‘Approved’.

Detail form: show the approved Group Request.

 

STEP 5: Back in SharePoint we can confirm the request status for Joanne’s Group has been updated to ‘Approved’ in the listview below:

---

NEXT STEPS:

Now that we have a SharePoint list populated with Group Requests, we can configure a Flow to call an Azure Function to automatically provision a Group for any that are approved. Stay tuned for my next post where I’ll show how this is done.

Thanks for reading.

-JCK