The native application approval functionality within Microsoft Endpoint Configuration Manager, or MECM (which is still often referred to as SCCM, ConfigMgr, and Configuration Manager) originally only allowed defined MECM admins to approve application requests from the Application Catalog and Software Center using the ConfigMgr/MECM 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 user’s 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/MECM 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 small feature gap in led me to the following idea which may suit the need for many who are waiting for the application approval functionality in the ConfigMgr/MECM 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 from the e-mail address that your ConfigMgr is sending application approvals from. For each application which requires approval, set the approval to go to this e-mail account so that the flow is automatically triggered each time an approval comes in from ConfigMgr. 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 MECM / 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).
Note: By default, the remove HTML step will be called “HTML_to_text” so if you don’t rename your step, be sure to change “Convert_Email_body_from_html_to_text” to “HTML_to_text”.
uriComponentToString(replace(uriComponent(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:
Note: By default, a new “Compose” step will be named “Compose” so if you didn’t rename your first Compose step, be sure to change “Remove_Linefeeds” to “Compose” here, or whatever else you renamed it to. Spaces in the name need to be replaced with underlines in an expression, so be aware of that also.
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 Azure AD (synced via Azure AD 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.
Note: By default, a new “Compose” step will be named “Compose” so if you don’t rename your previous steps, be sure to change “Remove_Linefeeds” to “Compose” here.
I did this using the following expression:
4. Uses the DisplayName to grab the user’s e-mail address (“Mail” property) using the Office365 Users connector’s “Search for users” flow action. You’ll need to use the output from the previous “DisplayName” action, which should now be equal to the display name of the user – ex: “John Doe”. You can validate this by running the flow and looking at the results of the run to make sure it looks right, and that it finds the correct user.
5. Uses the user’s “Mail” property from the previous step to look up the user’s manager (the manager is typically automatically already syncing if you’re using Azure AD Connect) using the Office 365 Users connector.
6. 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 Azure AD and you have Cloud Management Gateway (CMG) enabled along with enabling the new Admin Service 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/MECM 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/MECM.