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.

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.)
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
   • Automation Actions on iOS
   • Automation Actions on Windows
   • Automation Actions on macOS
   • Automation Actions on Apple TV
   • Automation Actions on Linux
   • Automation Actions on Zebra Printer
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

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 Evaluation

Event triggers are evaluated when the relevant device information is updated in Hexnode UEM. Device information can be refreshed through device scans, which can be initiated manually or scheduled to run automatically. When the configured event condition is detected, the associated automation is executed.

a. Deployment

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.

b. SIM

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.

c. Compliance

Pre-requisites:

The Compliance trigger requires a Compliance Policy to be associated with the targeted devices. The On Location Compliance and On Location Non-Compliance triggers require a Location Tracking policy to be associated with the target devices. The required geofence 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.

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.

d. Inactivity

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.

e. Battery

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.

f. Applications

Pre-requisites:

The Wi-Fi Data Usage Apps, Mobile Data Usage Apps, and Total Data Usage Apps triggers require a Network Data Usage Management 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.

g. Device

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.

h. Kiosk

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.

i. Agent Permission

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.

j. Group Membership

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.

k. Geofence

Pre-requisites:

For the geofence event triggers to function, a Location Tracking 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.

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.