This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
The native application approval functionality within Microsoft Endpoint Manager, or MEM (which is still often referred to as SCCM, ConfigMgr, and Configuration Manager) originally only allowed defined MEM admins to approve application requests from the Application Catalog and Software Center using the ConfigMgr/MEM administrator console. Starting with ConfigMgr 1810, you could also begin making pre-approved machine based pre-approval requests devices with no user required, allowing you to install applications in real-time. Additionally, e-mails could be sent to a defined approver, or list of approvers for each application that is deployed by typing in e-mail addresses of approvers into each application deployment at deployment type. This feature is certainly coming along.
One thing that I often hear from customers regularly is "I want to have my users' managers approve the applications, since they are going to ultimately be the ones responsible for covering the additional licensing costs out of their cost center." Unfortunately, you can only set one or more static e-mail address or DLs on each application deployment. This isn't easily possible today without having someone receive the e-mails, look up the requester's manager, and manually forwarding them the ConfigMgr/MEM generated approval e-mail.
I've been diving head-first into any and every chance to create PowerApps and Power Automate (Flows) to harness the power of these ultra powerful low-code/no-code application creation platforms. This gap in the product led me to come up with the following idea which may suit the need for many who are waiting for the application approval functionality in the ConfigMgr/MEM product to further mature in the Application Approval feature.
First, I had my customer make and choose an "Application approval" e-mail account to use. All applications requiring approval would be set to automatically e-mail this mailbox any time an end-user requests an application from Software Center.
Next, I created a Flow using Microsoft Power Automate which is triggered each time a new e-mail is received by this account. This Flow does not use any premium Power Automate connectors, so you can utilize these with the license included with an Office 365 subscription. The automatically generated e-mail from MEM / ConfigMgr looks like the following:
...and the Flow I came up with does the following:
1. Converts the received e-mail body from HTML to TEXT using the Content Conversion - HTML to TEXT (Preview) action which magically strips all HTML tags and headings from the body.
To further simplify getting to the interesting values I need to determine the submitting user's manager, I also removed all linefeed (LFs) using a Compose action with the expression. %0A is the ASCII code for a line feed, so I stripped them out by replacing them with nothing (by using two apostrophes and no space between them):
(body('Convert_Email_body_from_html_to_text')), '%0A', ''))
2. Determines how many characters are in the user's DisplayName by using the dash ("-") to subtract 10 characters from the total using the following expression:
add(int(indexOf(outputs('Remove_Linefeeds'), ' -')), -10).
I realized I needed to be careful with this, as some ladies use a dash in their last name to indicate they're keeping both their maiden and married names. This is the reason I added a space after the ' and before the - so it’s ' -' rather than '-' so it will always skip over any dashes that occur in their last name since they don't have spaces.
3. Uses the above values to get the user's DisplayName attribute from AzureAD (synced via AzureAD Connect), which begins at the index (character) number 9 of the resulting string output from the "Remove Linefeeds" action, and ends at at the index of the dash after the user's DisplayName. I did this using the following expression:
substring(outputs('Remove_Linefeeds'), 9,outputs('Index_of_dash')).
4. Users the DisplayName to get the user's e-mail address using the Office365 Users connector.
Uses the user's e-mail address to look up the user's manager (also automatically synced using AzureAD Connect) using the Office365 Users connector.
5. Forwards the e-mail automatically sent by the application approval request feature to the user's manager.
The user's manager will receive the e-mail and can determine whether to approve or deny the request, and whichever link they click will work. If the user is authenticated via AzureAD and you have Cloud Management Gateway (CMG) enabled along with enabling the new AdminService feature of the SMS provider, the manager can also approve the requests when connected to the Internet by way of CMG. Nice!
Here's the full Flow:
Here's a zoomed version of the last two steps which gets the user's manager and forwards the e-mail to them:
The automatically generated e-mails sent from ConfigMgr/MEM when an application approval request is submitted by an end user is formatted in a predictable way. If it's changed in a future version, these flows may need adjusted to match, depending on what changes. Once the HTML and LineFeeds are removed, the whole e-mail is on one nice long string on a single line. I felt this would be much easier to get to the important stuff!
You could also optionally log some or all of the interesting values from the e-mail to a Sharepoint list, Excel Spreadsheet, or whatever your heart desires to keep track of the requests outside of ConfigMgr/MEM.
Enjoy!