Be able to add uninstall-only scripts for discovered apps.

Option to remove devices from Radar Tracking groups when they get the latest version.

Support for users to define their own dependencies. Support for having dependencies be created as separate apps in Intune.

On-demand and periodically sent reports for app update and deployment information

Support analysis and deployment of ARM Windows apps.

Support categories, developer, other properties that exist in Intune but not in Robopack - and this support needs to exist for flows. Categories, minimum OS version, comments, developer…

Support the Intune features for specifying an App availability date and time, and an app installation deadline date and time.

US, Aus, etc - local copies of Robopack that ensures their data is only stored in their own region

More items for notifications, allow notifications for specific tenants

We would like to be able to use the Test script function with different Custom app settings when using multiple tenants. Today it will only use the All tenants configuration.

Enhance Package Options so administrators can define precise device requirements before an application installation or update runs.

Key options are Configure additional requirement rules and Script-based requirement checks.

These should allow administrators to define custom logic that determines whether installation proceeds and better align with Intune UI and functionality.

Administrators can implement logic such as:

Install X only if Y is not already installed.

This prevents unintended downgrades or overwriting existing software and supports environments where different editions of the same application coexist (e.g., Reader vs. Pro).

Allow the upload of a newer MSI file for existing custom apps.

Supporting French, German

Support for uploading new/multiple versions of custom apps, similar to the way that multiple versions are available for some Instant Apps.

When a new app is published, Roboback will clone the existing wave assignments, but the old (superseded) app keeps the same group assigned, and this creates issues.

Superseded apps are NOT excluded from evaluation(according to Microsoft), so when we have a required app with 3 supersedence, all assigned, then IME will trigger evaluation for all 4 apps.

You can do the math for how many apps you have set as required and how many superseded versions set in Robopack will run simultaneous in background each hour.

I'd like to have an option to revert the deployment to an earlier version - e.g. we had an issue on all affected clients with an update of AWS VPN Client. I had to manually configure everything in Intune (Remove Assignments, Supersedence, Add Supersedence to the previous version to remove the new version)

This would be extreme helpful in such cases. Otherwise it would be helpful to have a Tutorial in the Docs how to perform a rollback to a previous version

When removing an App from a Patch Group or Patch Flow, the wizard asks to also remove the App from Intune. But it never removes the Entra Groups which were used for it (Available, Required and Uninstall). In some cases, this could be useful (and in others, the groups must be kept).

A toggle to also delete the corresponding groups would help and the admin can decide what to do. Naming the groups in the interface will help with that decision. 

Support multifactor authentication for local Robopack accounts

Default categories initially, custom to follow

We need more granular permissions control. For example, the permission to upload to Intune should be a seperate control. I should not have to grant Org Admin to a user that just needs to manage packages in Robopack and Intune. This breaks Least Privilege models.