I was working with a customer recently that is leveraging Workspace ONE Launcher for Android to lock devices into either a single use or multi-app launcher mode. However, these devices are out in the field and in a location where if the device is taken out of Launcher either maliciously or otherwise, the only way to find out about it is to have the local employee tell IT, or manually check the device list view to see if the device is reporting that Launcher is assigned, but not installed or set to active.

This sounds like a tough thing to solve, right? Well, with Workspace ONE Intelligence and the integration with Workspace ONE UEM, we can automatically fix this, keep track of what devices are falling out of compliance and notify someone when a device is remediated.

Let’s take a look at the criteria needed to accomplish this. From Workspace ONE UEM, open up the Intelligence console and open the Automation option.

We’ll create a new automation Workflow. To keep things flexible, we’ll start with a Custom Workflow.

For the criteria, the bare minimum needed for this to work are the following two options.

However, there could potentially be an overlap with Android devices that aren’t required to use Launcher – so I prefer to provide more specific details.

Let’s talk through each of the choices here and why I selected them:

• Launcher Active Equals False
  • This criteria is what will identify devices that are showing the status we looked at previously in the UEM attributes where a device should be in Launcher mode, but for whatever reason is not.
• Platform Equals Android
  • This is sort of a safety net for future proofing this automation, right now Launcher only exists for Android, but it’s better to be as specific as possible with an Automation to limit any unexpected actions. In the future if there is a Launcher status for another platform, this ensures that our automation only tries to apply for Android Launcher.
• Device Tags Contains None Of “LauncherBypass”
  • This one sounds counter intuitive, but the idea here is what if a device administrator has a legitmate reason to exit launcher to do some sort of troubleshooting or maintenence work. They don’t wan to be kicked back into Launcher mode within 30 seconds, right? By simply applying the tag I created “LauncherBypass” that tells the Automation to not apply to this device. Simple to apply and simple to remove!
• Device Organization Group Name Includes <My OGs that have Launcher Devices in them>
  • This is another safety net for my automation – for my lab example, there may be Launcher use cases where I want to be able to exit Launcher without the automation taking place.

Cool. So now we’ve selected the criteria for something to happen – but what do we do need to do to resolve Launcher not being set as active? The simplest fix is to re-push the Launcher Profile to the device. This will both force Launcher to reopen and set to the default, as well as reinstall the Launcher application if it was maliciously removed or accidentally removed. What does that process look like?

The action is very simple since we’re already tied into Workspace ONE UEM. We choose the “Install Profile” action from Workspace ONE UEM.

The automation allows you to search for existing Profiles, instead of having to know the unique database ID for the Profile.

You can click the green “TEST” button to test using the API call to push the profile to a device. Head’s Up: You’ll need to know the Device ID in order for this part to work. To find that unique ID, in UEM open the Device Details view and look for the device’s number in the URL (example below in bold). When the automation runs, it will dynamically populate the correct Device ID – you only need to know a device ID to test the action out in Intelligence.

https://cn1234.awmdm.com/AirWatch/#/AirWatch/Device/Details/Summary/119

You can add on as many Actions as you want to occur as a result of this Automation running. For my example, I also sent a push notification to the device letting the end-user know that they aren’t allowed to exit Launcher. You could just as easily trigger an email to your admins to let them know a device is out of compliance, add a tag to a device (HasExitedLauncherBefore) – so you can keep track of repeat offenders, or any other action via API calls — maybe you want to trigger a Slack notification, or remove something on the device. Up to you!

When you have all the actions you’d like to run with this automation, choose “Save & Enable”

The end-result is that a device that should be running Launcher, but isn’t is very quickly and automatically remediated.

Before you enable the automation, you can view any potential impact – so if your filtering criteria above wasn’t specific enough you can avoid accidentally impacting devices you’re not trying to remediate.

You can also view what devices and actions have happened with this automation – in my lab you can see multiple tests in which I added and removed tags, exited launcher, etc.

What does it look like for an end-user? Pretty much like what it looks like when launcher installs initially, except this time we sent a push notification letting them know they aren’t allowed outside of Launcher on this device.

That’s it! I hope this was helpful! What ways are you leveraging Intelligence Automations in your environment?