# Event Triggers in Hexnode UEM Executive Summary ----------------- Automations built on a **fixed schedule** can **only respond** when the scheduled run occurs, which may leave a compliance violation, a critical battery level, or a security-relevant permission change unaddressed until the next scheduled check. Event-triggered automations instead **run when the configured event condition is detected**. This capability spans eleven trigger categories — deployment, SIM, compliance, inactivity, battery, applications, device, kiosk, agent permission, group membership, and geofence — configured through the same Automate workflow used for scheduled automations, with **Event** selected as the trigger type. Trigger availability varies across the eight supported platforms, with some categories such as SIM monitoring, inactivity detection, per-app data usage, and agent permission tracking supported only on Android. [See the Platform Support Matrix for the complete platform-wise breakdown before configuring an automation.](https://www.hexnode.com/mobile-device-management/help/event-triggers-hexnode-uem/#trigger-catalog-platform-support-matrix) Events vs. Event Triggers ------------------------- An **event** is a status change on a managed endpoint — enrollment, a compliance violation, a low battery state, and similar changes. An **event trigger** is the rule, configured within an automation, that detects a specific event and executes the automation’s assigned actions on the target device. Available event triggers vary by platform — a trigger available on Android may not exist on iOS, Windows, macOS, Apple TV, Linux, visionOS, or Zebra Printer, and vice versa. The full support breakdown is in the Trigger Catalog below. Configuring an Event-Triggered Automation ----------------------------------------- 1. Log in to the Hexnode UEM portal. 2. Go to the **Automate** tab. 3. Click **New Automation** and select the target platform. 4. Click **Create New Automation → Quick**. 5. Under **Triggers and Schedules**, select **Event** and choose the required event trigger. Each automation supports one trigger. 6. Select the event trigger for your platform and use case. *[(See the Trigger Catalog below — available triggers vary by platform.)](https://www.hexnode.com/mobile-device-management/help/event-triggers-hexnode-uem/#trigger-catalog-platform-support-matrix)* 7. Under **Choose Actions**, select the actions to run when the event occurs. Available actions vary by platform; see the platform-specific action references below: - [Actions on Android](https://www.hexnode.com/mobile-device-management/help/automate-actions-on-android/) - [Automation Actions on iOS](https://www.hexnode.com/mobile-device-management/help/manage-automation-on-ios/) - [Automation Actions on Windows ](https://www.hexnode.com/mobile-device-management/help/automate-repetitive-tasks-on-windows/) - [Automation Actions on macOS ](https://www.hexnode.com/mobile-device-management/help/automate-tasks-on-macos/) - [Automation Actions on Apple TV ](https://www.hexnode.com/mobile-device-management/help/automating-tvos/) - [Automation Actions on Linux ](https://www.hexnode.com/mobile-device-management/help/automate-regular-tasks-in-linux/) - [Automation Actions on Zebra Printer ](https://www.hexnode.com/mobile-device-management/help/automate-zebra-printer-actions/) 8. Under **Assignments**, configure which devices the automation applies to: - Include the required device or user groups. - Exclude specific device or user groups. - Add filters to further refine devices within the included groups. 9. Under **Review**, confirm the configured settings. 10. Click **Save** to create the automation. Trigger Catalog: Platform Support Matrix ---------------------------------------- This table lists all available event triggers in Hexnode UEM and shows their platform support across Android, iOS, Windows, macOS, Apple TV, Linux, visionOS, and Zebra Printer. All available event triggers and their platform support, at a glance. See the category tables below for descriptions, default values, and configuration notes. Event trigger support by platformTriggerAndroidiOSWindowsmacOSApple TVLinuxvisionOSZebra PrinterOn Device Enrollment✓✓✓✓✓✓✓✓On Device Re-Enrollment✓✓✓✓✓✓✓✓On SIM Insertion✓✗✗✗✗✗✗✗On SIM Removal✓✗✗✗✗✗✗✗On SIM Swapped✓✗✗✗✗✗✗✗On Device Compliance✓✓✓✓✓✓✓✓On Device Non-Compliance✓✓✓✓✓✓✓✓On Location Compliance✓✓✓✓✗✗✓✓On Location Non-Compliance✓✓✓✓✗✗✓✓On Device Inactive✓✗✗✗✗✗✗✗Device Inactive for Specific Time✓✗✗✗✗✗✗✗Battery Capacity✓✓✓✓✗✓✓✓Battery Temperature✗✗✗✓✗✗✗✗Battery Status✗✗✗✓✗✗✗✗Wi-Fi Data Usage Apps✓✗✗✗✗✗✗✗Mobile Data Usage Apps✓✗✗✗✗✗✗✗Total Data Usage Apps✓✗✗✗✗✗✗✗Apps Installed✓✓✓✗✗✗✗✗Missing Apps✓✓✓✗✗✗✗✗App Version Match Status✓✓✓✗✗✗✗✗App Version Mismatch Status✓✓✓✗✗✗✗✗Total Data Usage✓✓✗✗✗✗✗✗Device Storage Capacity✓✓✓✓✗✓✓✓Kiosk Activated✓✓✓✗✓✓✗✗Kiosk Exited✓✓✓✗✓✓✗✗Permissions of Agents✓✗✗✗✗✗✗✗Added into Device Groups✓✓✓✓✓✓✓✓Removed from Device Groups✓✓✓✓✓✓✓✓Device Within Geofence✓✓✓✓✗✗✓✗Device Outside Geofence✓✓✓✓✗✗✓✗Event Trigger Evaluation ------------------------- Event triggers are evaluated when the relevant device information is updated in Hexnode UEM. Device information can be refreshed through [device scans](https://www.hexnode.com/mobile-device-management/help/scan-devices-remotely-using-hexnode-uem/), which can be initiated manually or scheduled to run automatically. When the configured event condition is detected, the associated automation is executed. Event Trigger Categories ------------------------ This table describes the deployment event triggers available in Hexnode UEM, including device enrollment and device re-enrollment. #### a. Deployment TriggerDescriptionOn Device EnrollmentTriggers when a new device completes enrollment and appears active in the portal. On Device Re-EnrollmentTriggers when a device successfully re-enrolls and regains active status.**When should you use enrollment triggers?** Use enrollment triggers to make sure every device gets the right configuration the moment it enters or returns to management, without waiting for an admin to act. **Example: Configuring new and re-enrolled devices automatically** Pair the **On Device Enrollment** and **On Device Re-Enrollment** triggers with the **Associate Policy** action. When a device enrolls, Hexnode applies the policy that holds your corporate Wi-Fi configuration and passcode requirements, so the device is secure and connected from the start. Re-enrollment matters just as much. A device that has been reset, re-provisioned, or reassigned may come back without its earlier configuration. The **On Device Re-Enrollment** trigger restores the right policy automatically, so the device doesn’t stay non-compliant between re-enrollment and manual review. This table describes the SIM event triggers available on Android devices, including SIM insertion, removal, and SIM swapping. #### b. SIM TriggerDescriptionOn SIM InsertionTriggers when a SIM card is detected in the device slot.On SIM RemovalTriggers when a SIM card is removed or becomes undetected by the hardware.On SIM SwappedTriggers when the system detects a change in the SIM card currently in use.**When should you use SIM-based triggers?** SIM-based triggers let you respond automatically when a managed device’s SIM changes. That change can signal theft, misuse, or a policy violation. **Example: Securing a lost or stolen device** A managed device holding corporate data is lost or stolen, and someone replaces its SIM. When the **On SIM Swapped** trigger detects the change, the automation puts the device in **Lost Mode**. Lost Mode locks the device, shows a custom message and contact number on the screen, and lets IT find the device so it can be recovered. If it can’t be recovered, admins can escalate to a remote wipe to protect corporate data. **Other common uses:** - Fetch device location when a corporate SIM is replaced with a personal one. - Block access to corporate apps until the change is reviewed. Tip: SIM changes aren’t always malicious. Employees may switch carriers or use a local SIM while traveling. To avoid locking out legitimate users, scope the automation to high-risk device groups. This table describes the device and location compliance event triggers, including compliance and non-compliance status changes. #### c. Compliance TriggerDescriptionOn Device ComplianceTriggers when the device meets all conditions in the assigned Compliance Policy.On Device Non-ComplianceTriggers when the device violates one or more conditions in the assigned Compliance Policy.On Location ComplianceTriggers when the device enters the geofence configured in its location-based compliance policy.On Location Non-ComplianceTriggers when the device moves out of the geofence configured in its location-based compliance policy. **Pre-requisites:** The **Compliance** trigger requires a [Compliance Policy](https://www.hexnode.com/mobile-device-management/help/how-to-create-a-compliance-policy-for-devices/) to be associated with the targeted devices. The **On Location Compliance** and **On Location Non-Compliance** triggers require a [Location Tracking](https://www.hexnode.com/mobile-device-management/help/how-to-configure-location-tracking-with-hexnode-mdm/) policy to be associated with the target devices. The required [geofence](https://www.hexnode.com/mobile-device-management/help/geofencing-location-based-mdm-restriction/) must be configured for the location-based compliance setup. **When should you use compliance triggers?** Use compliance triggers to respond automatically when a device’s compliance status changes. Hexnode can then restrict or restore access without an admin having to watch compliance reports. **Example: Restricting and restoring access based on compliance** A device falls out of compliance because its OS is outdated or its passcode doesn’t meet requirements. The **On Device Non-Compliance** trigger fires, and the automation uses **Associate Policy** to apply a restrictive policy that limits access to corporate apps until the device is fixed. Once the user fixes the issue, the **On Device Compliance** trigger fires and associates the standard policy again. Full access comes back automatically. Together, the two triggers form a self-correcting loop: the device is restricted while it’s at risk and restored once it’s compliant, with no manual steps. **Other common uses:** - Notify the user when a device becomes non-compliant. - Detect when a device becomes non-compliant, allowing the admin to identify the cause and take appropriate action, such as pushing an OS update if an outdated OS version caused the non-compliance. Tip: Make the restrictive policy strict enough to protect corporate data but not so strict that the user can’t fix the problem. For example, keep access to the apps or settings needed to update the OS or reset the passcode. **When should you use location compliance triggers?** Use location compliance triggers when a device’s security or configuration should depend on where it is. Examples include devices that must stay on premises, or settings that should apply only inside a specific site. **Example: Securing devices that leave an approved area** A retailer’s handheld scanners are meant to stay inside the store. If one leaves the geofence set in its location-based compliance policy, the **On Location Non-Compliance** trigger fires and the automation puts the device in **Lost Mode**. The device is locked, shows a message with contact details, and can be located for recovery. When the device is back inside the geofence, the **On Location Compliance** trigger fires and associates the standard working policy, **though Lost Mode must still be deactivated manually**. **Other common uses:** - Apply stricter settings inside secure areas, such as turning off the camera in a lab or restricted facility. - Apply site-specific configurations, such as local Wi-Fi, when a device arrives at a branch office. Tip: Location triggers depend on accurate location data. Make sure location services are turned on and set the geofence radius with some margin for GPS drift, so devices near the boundary don’t switch back and forth between compliant and non-compliant. On personally owned devices, check local privacy rules and tell users about location tracking before you turn it on. This table describes the Android-only inactivity event triggers, including device inactivity and inactivity for a specific configured duration. #### d. Inactivity TriggerDescriptionOn Device InactiveTriggers when the device transitions to an inactive/idle state.Device Inactive for Specific TimeTriggers when the device remains inactive for an admin-configured duration (5–100 minutes). **Pre-requisites:** Both inactivity triggers require the **Alarms and reminders** permission for the Hexnode UEM app on **Android 12 and later** devices. Without this permission, the triggers will not execute. For corporate-owned (Device Owner) devices, administrators can **automatically grant this permission remotely** during enrollment via the Hexnode Enrollment Profile. Alternatively, it can be enabled manually on the device by navigating to **Settings > Apps > Special app access > Alarms & reminders**. **When should you use inactivity triggers?** Use inactivity triggers to act automatically when a device is left idle. Common goals are protecting unattended devices and getting shared devices ready for the next user. **Example: Resetting shared devices between users** In a hospital or warehouse, several workers share Android devices across shifts. If a worker leaves a device unattended, the **Device Inactive for Specific Time** trigger fires once it has been idle for the set time, for example 15 minutes. The automation can then associate a policy that locks the device or returns it to its default state, so the next user doesn’t see the previous user’s session. **Example: Protecting a device that may be lost** If a device holding sensitive data stays idle for the maximum duration you set, the automation can put it in **Lost Mode**. The device is locked, shows recovery contact details, and can be located, often before anyone reports it missing. **Other common uses:** - Notify IT when a device assigned to a critical role stays inactive. - Enforce a quicker screen lock on high-risk devices when they go idle. Note: Match the action to how often the trigger fires. **On Device Inactive** fires each time the device goes idle, so use it for lightweight actions. Keep restrictive actions like **Lost Mode** for **Device Inactive for Specific Time**, and set the duration long enough that normal breaks don’t lock users out. This table describes battery health event triggers, including battery capacity, battery temperature, and battery status. Battery temperature and battery status triggers are available only on macOS. #### e. Battery TriggerDescriptionRangeDefaultBattery CapacityTriggers when charge level goes below a defined percentage.5–100%5%Battery TemperatureTriggers when the internal battery temperature reaches the thermal limit specified during configuration. macOS only.5–75, with Celsius or Fahrenheit as selectable unit5Battery StatusTriggers on a specific battery status: charging, not charging, or fully charged. macOS only.——**When should you use battery triggers?** Use battery triggers to catch power and hardware problems early, before a device shuts down mid-task or a battery fault turns into a support ticket. **Example: Preventing downtime on field devices** Field technicians depend on their devices all shift. When a device’s charge drops below 20%, the **Battery Capacity** trigger fires and the automation notify the user or IT. The user can charge the device before it dies during a job. **Example: Detecting overheating Macs (macOS only)** Sustained high temperatures can shorten battery life and point to a hardware or software problem, such as a runaway process. When a Mac’s battery temperature reaches the limit you set, the **Battery Temperature** trigger fires. The automation can alert the user or run a diagnostic script, so the problem gets looked at before it damages hardware. Tip: Set thresholds that suit how the device is used. A low limit such as 10% avoids too many alerts on devices that are charged daily. A higher limit such as 30% suits devices that must last a full shift. For temperature, set the limit well above normal operating temperature so routine heavy workloads don’t cause false alerts. This table describes application-level event triggers, including app data usage, app installation, missing apps, and app version match or mismatch status. #### f. Applications TriggerDescriptionRangeDefaultWi-Fi Data Usage AppsTriggers when cumulative Wi-Fi data use of selected apps reaches a limit.1–1000 MB/GB100 MBMobile Data Usage AppsTriggers when cellular data use of selected apps reaches a limit.1–1000 MB/GB100 MBTotal Data Usage AppsTriggers when total data use (Wi-Fi + cellular) of selected apps reaches a limit.1–1000 MB/GB100 MBApps InstalledTriggers when a selected application is installed on the device.——Missing AppsTriggers when a required application (per the device’s required apps policy) is missing or uninstalled. ——App Version Match StatusTriggers when the installed app version matches the version in the Hexnode app inventory.——App Version Mismatch StatusTriggers when the installed app version does not match the version in the Hexnode app inventory.——**Pre-requisites:** The **Wi-Fi Data Usage Apps**, **Mobile Data Usage Apps**, and **Total Data Usage Apps** triggers require a [Network Data Usage Management](https://www.hexnode.com/mobile-device-management/help/how-to-manage-mobile-data-usage-with-hexnode-mdm/) policy to be configured and associated with the target devices. **When should you use application triggers?** Use application triggers to keep the app setup on devices where you want it: required apps present, apps up to date, unapproved apps flagged, and app data use under control. **Example: Restoring a business-critical app automatically** Your team depends on a line-of-business app every day. If a user removes it, the **Missing Apps** trigger detects that a required app is gone and runs the **Install Application** action to reinstall it. Employees get their tools back without raising a ticket. **Example: Keeping apps on the approved version** When the **App Version Mismatch Status** trigger detects that an installed app doesn’t match the version in the Hexnode app inventory, the automation can push the approved version. When the device reports a matching version, the App Version Match Status trigger can associate a policy that restores access to resources that need that version. **Example: Controlling cellular data costs** Streaming or large-sync apps can use up corporate data plans quickly. When selected apps pass 2 GB of cellular data, the **Mobile Data Usage Apps** trigger fires. The automation can associate a policy that limits those apps to Wi-Fi. **Other common uses:** - Monitor total data use for high-bandwidth apps with **Total Data Usage Apps** to find devices that need a bigger plan or a policy change. Tip: Set data limits that match how you bill and review usage. If your carrier plan resets monthly, choose limits that give an early warning, for example 80% of the monthly allowance, rather than an alert once the plan is already used up. This table describes device-level event triggers for total data usage and device storage capacity. #### g. Device TriggerDescriptionRangeDefaultTotal Data UsageTriggers when cumulative device-wide data consumption reaches a limit.1–1000 MB/GB100 MBDevice Storage CapacityTriggers when remaining internal storage falls below a threshold.1–1000 MB/GB100 MB**When should you use device triggers?** Use device triggers to catch device-wide resource problems, such as data overuse or low storage, before they cause unexpected costs, failed updates, or poor performance. **Example: Staying within corporate data plans** Your organization provides devices with a fixed monthly data plan. When a device’s total data use reaches 8 GB of a 10 GB allowance, the **Total Data Usage** trigger fires. The automation notifies the user, so usage can be cut back before overage charges start. **Example: Preventing failed updates and app installs** OS updates and app deployments fail when a device doesn’t have enough free space. When available storage drops below 5 GB, the **Device Storage Capacity** trigger fires. The automation can alert the user to free up space. **Other common uses:** - Find devices with unusually high data use, which may point to misuse or a misbehaving app. Then use **Total Data Usage Apps** to find the app responsible. - Flag shared or kiosk devices that are filling up with cached content, so they can be cleaned up. Note: **Total Data Usage Apps** (under Applications, Android only) tracks the combined data use of the apps you select when setting up the trigger. **Total Data Usage** (under Device, Android and iOS) tracks the device’s total data use across all apps. Tip: Set the storage threshold above the space your largest routine update needs. A few GB is a safer buffer than the 100 MB default, which leaves little room to act before the device runs out of space. This table describes kiosk event triggers for changes in the device’s kiosk lockdown state. #### h. Kiosk TriggerDescriptionKiosk ActivatedTriggers when the device successfully enters locked-down kiosk mode.Kiosk ExitedTriggers when the device is released from kiosk mode and returns to its standard interface.**When should you use kiosk triggers?** Use kiosk triggers to confirm that purpose-built devices stay locked down, and to respond right away if one leaves kiosk mode. **Example: Responding to unexpected kiosk exits** A retailer runs self-service check-in tablets in single-app kiosk mode. If a tablet leaves kiosk mode outside of planned maintenance, the **Kiosk Exited** trigger fires. The automation can associate a restrictive policy, alert IT, or put the device in **Lost Mode**, so a customer can’t browse the device’s full interface or change its settings. **Example: Applying kiosk-specific settings on activation** When a device enters kiosk mode, the **Kiosk Activated** trigger fires and the automation associates a policy with the settings the kiosk needs, such as a dedicated Wi-Fi network or stricter restrictions. Every kiosk ends up set up the same way without manual follow-up. **Other common uses:** - Keep an audit trail of kiosk exits on devices in regulated or public-facing settings. Tip: Planned maintenance also fires **Kiosk Exited**. To avoid locking out technicians or sending false alerts, scope security actions to device groups not under maintenance, or move devices out of the automation’s target group before servicing them. This table describes the Android-only agent permission event trigger, which detects when an agent-level permission is granted or revoked. #### i. Agent Permission TriggerDescriptionPermissions of AgentsTriggers when an agent-level permission (e.g., Activate VPN, Notification access) is granted or revoked. **When should you use agent permission triggers?** The Hexnode UEM app needs certain Android permissions to run features such as location tracking, web filtering, and inactivity detection. Use agent permission triggers to find out when those permissions change, so features don’t stop working without anyone noticing. **Example: Protecting features that depend on permissions** Your organization uses inactivity triggers on field devices. If a user revokes the Alarms & Reminders permission, those features stop working. The **Permissions of Agents** trigger detects the revocation, and the automation can associate a restrictive policy until the permission is granted again. **Example: Keeping web filtering in place** If Hexnode uses a VPN connection to enforce web content filtering, a user could try to get around it by revoking the **Activate VPN** permission. The trigger detects this, so IT can respond before the device is used unfiltered. **Other common uses:** - Confirm that required permissions have been granted after enrollment, especially on BYOD and work profile devices. - Track how often users revoke permissions, to spot training needs or possible tampering. Tip: Permission changes have the most impact on devices where users control the permissions, such as BYOD and work profile enrollments. Focus these automations there, and pair them with other triggers (inactivity, location compliance) that depend on the same permissions. This table describes the group membership event triggers that detect when a device is added to or removed from device groups. These triggers have universal platform support. #### j. Group Membership TriggerDescriptionAdded into Device GroupsTriggers when the device is added to one or more designated groups. Removed from Device GroupsTriggers when the device is removed from a selected group.**When should you use group membership triggers?** Use group membership triggers to turn group changes into workflows. Moving a device into or out of a group can start onboarding, offboarding, or security actions without extra steps. **Example: Starting a lost-device response** Create a group called “Reported Lost”. When IT or a helpdesk agent adds a device to it, the **Added into Device Groups** trigger fires and puts the device in **Lost Mode**. The whole team can then handle a lost device the same way: move it into one group, and the response runs automatically. **Example: Offboarding devices automatically** When an employee leaves or a device is retired, removing it from the “Active Devices” group fires the **Removed from Device Groups** trigger. The automation can remove corporate policies, lock the device. Offboarding is the same every time, and nothing gets missed. **Example: Department-specific onboarding** When a device joins the “Sales” group, the trigger associates the sales team’s policy, with its CRM access, VPN, and restrictions. Moving the device to another department’s group applies that group’s setup instead. **Other common uses:** - Respond to dynamic group changes. When a device automatically joins a dynamic group because it matches criteria such as an outdated OS, the trigger can start a fix. - Pause kiosk or security automations during maintenance by moving devices into a “Maintenance” group. Tip: Bulk moves fire the trigger for every device at once. Before you move large numbers of devices, test the automation on a small group so an unexpected action, such as Lost Mode, doesn’t hit the whole fleet. This table describes geofence event triggers that detect when a device enters or moves outside the boundaries of a selected geofence. #### k. Geofence TriggerDescriptionDevice Within GeofenceTriggers when the device enters the boundaries of the geofence selected while configuring the trigger.Device Outside GeofenceTriggers when the device moves outside the boundaries of the geofence selected while configuring the trigger.**Pre-requisites:** For the geofence event triggers to function, a [Location Tracking](https://www.hexnode.com/mobile-device-management/help/how-to-configure-location-tracking-with-hexnode-mdm/) policy must be associated with the target devices. Selecting a geofence while configuring the event trigger alone is not sufficient. **When should you use geofence triggers?** Use geofence triggers to act on where a device is. You can secure devices that leave an approved area, or apply settings when a device arrives at a site. **Example: Securing devices that leave an approved site** A warehouse’s shared handheld devices should never leave the site. If one leaves the configured geofence, the **Device Outside Geofence** trigger runs the **Lock Device** and **Scan Device Location** actions. The device is secured right away, and its current location is captured to help recover it. **Example: Applying site-specific settings on arrival** When a device arrives at a branch office, the Device Within Geofence trigger can associate a policy with that site’s Wi-Fi and resources, so employees are ready to work as soon as they arrive. **Geofence triggers vs. Location Compliance triggers** Both respond to geofence boundaries but work differently. Location Compliance triggers depend on a location-based compliance policy and fire when the device’s compliance status changes. Geofence triggers work directly with the geofence you pick in the trigger, with no compliance policy needed. Use Location Compliance triggers when location is part of your compliance rules. Use Geofence triggers for simple “enter or leave this area” automations. Tip: Set the geofence radius with room for GPS drift, so devices near the boundary don’t keep switching between inside and outside. On personally owned devices, check local privacy rules and tell users about location tracking before you turn it on. Troubleshooting Event Triggers ------------------------------- **Issue 1: Android inactivity event trigger does not fire** **Fix:** Ensure that the **Alarms and Reminders** permission is granted to the Hexnode UEM app on the Android device. Without this permission, **On Device Inactive** and **Device Inactive for Specific Time** cannot execute.