Automated actions allow you to change the status of a device from a state of compliance to a state of non-compliance based upon specific conditions. For example, you can set an Automated Action to change a device to a state of Out Of Compliance=True if the device has been jailbroken or rooted, if the user disabled location services on the device, or if the user installs a blacklisted application.
In a cases where a user's device is put into an out of compliance state, and then the user fixes the device so that the device is in compliance, you will need to configure a policy to deploy a package that resets the device into a compliant state.
For example, let's say you want to define the following three compliance policies in your organization by using Device Manager Automated Actions:
Device Manager deploys packages to target devices. When you create your Automate Action compliance policies, you need to name your policies in a very specific way, so that they are run in the correct order.
Device Manager deploys packages according to their name, deploying those packages in an alphanumeric order. Thus, you want to make sure that you deploy your Compliance Reset Automated Action package first and that it does not reset any of the other Automated Action packages that are designed to track compliance device compliance.
When you name your policies, make sure that the global compliance reset policies deploy first and then deploy your Automated Action compliance deployment packages.
In the example above, you might want to create three packages to track device compliance, the Geo-fence, Blacklist, and Jailbreak polices. Automated Actions tracks the devices and sets the devices to Out of Compliance=False when the user violates the policy. You also want to be able to reset the devices when the user brings the device back into compliance.
For example, you want to reset the device property when the Device Manager detects that the device is out of compliance. You want this policy to run before any other policy. You can provide the name aaa-OOC-Reset so that it will run before the policies that can set a device out of compliance.
You can create an Automated Action by setting the device property to out of compliance if users disables location services on the device. If you want this policy to run after the reset policy, you can give the policy the name aab-location-services-disabled. You can then set the delay for a specific number of minutes so this policy runs after the compliance reset Automated Action that runs before this policy.
You can also create an Automated Action that sets the device property to out of compliance if users install a blacklisted app on their device. You can give the policy the name aac-blacklisted-app and set the delay for four minutes so it runs after the two policies preceding this one.
You can create an Automated Action to set the device property to out of compliance if users jailbreak or root their device. You can give the policy the name aad-jailbreak and set the delay to five minutes so it runs after the three policies preceding this policy.
Your last step to make sure that your compliance policies run in the correct order. To do so, create Deployment Packages and use the same names you used for the Automate Actions. You follow the same principles in naming that you use for Automated Actions. When you use this naming conventions, you can make sure that the packages deploy in the same order as the Automated Actions.