Is there a plan to provide more visibility to the supersedence portion of app deployment? For example, I  have an app that I deployed an update to that supersedes an existing deployment. If I deploy an app that supersedes both the update an the original deployment, then weeks later go back and delete the original deployment, I have to find the app that is preventing the deletion because of the supersedence relationship. 

In SCCM, I can at least see the offending app. In Intune, I'm not able to other than that there's a supersedence rule applied. 

We’re missing a way for Intune to detect unmanaged installations of “Available” assigned applications. Currently, updating or taking over management is difficult if the app wasn’t installed via Intune. This calls for workarounds, multiple versions of the same application and tweaked “Required” assignments.

A simple solution would be a “checkmark” similar to the “AutoUpdate” function in Supersedence. If checked, Intune would check if detection is met and mark the application as installed. This would make applications installed outside Intune manageable within Intune, allowing admins to update them via superseded versions.

The checkmark solution, compared to Intune automatically checking and detecting all “Available” assigned apps, minimises resource and time consumption on Intune Syncs.

I look forward to an insightful and constructive session.

Add the running process check like in ConfigMgr, before upgrading or superseding an application. If the native app is running, alert user first.

Will apps.microsoft.com installers be brought into the fold to follow settings like the built-in app store? Having students bypass the app store restriction by using the website is a large security hole and using workarounds to patch it is clunky and annoying. I have not investigated the new command line store but I fear it is another hole in app security and management.

Will there ever be a way to create a dynamic group of devices that have a particular program installed in Intune? I have this set up in Config Manager and this helps with program deployment. 

I have applications that autoupdate. This makes managing detection rules challenging. It's tempting to use the "IF Program Files <program> folder exists" rule, but that can cause headaches when the time comes to deploy a new updated app if it uses the same folder. In some cases, the ProductID code is the same. I would absolutely love an easier way to manage the detection rules for .MSIs and .EXEs that autoupdate. Is that something that can be considered? 

Given Microsofts push towards MSIX (which was diluted by opening up the MS Store to Win32 apps), it would be great if under the Enterprise App Management feature MS were able to repackage and offer up vendor apps in MSIX format where the vendor doesn't provide them as such.