Technical · Course T5Lesson 5 of 5
Geofences, Safe Drive, and compliance
8 min read- Configure a geofence with entry/exit alerts and in-fence restrictions
- Set up Safe Drive for fleet devices and explain its prerequisites
- Name the compliance dimensions and where violations surface
The controls so far wait for an admin to act. This lesson is about the ones that don't: rules that watch location, speed, time, and device state, and enforce themselves.
Geofencing: policy that knows where it is
In the Geofence section (Android and Windows policies — iOS doesn't have it), you draw circular zones on a map: click to place, drag to resize (200 m default radius), name it uniquely, toggle it active. Each zone carries three kinds of automation:
- Entry/exit alerts — In Fence and Out Fence email notifications to any mix of operator and custom addresses, configured independently per direction.
- In-fence device restrictions — disable camera, screen capture (with an optional WeSupport live-view exemption), Bluetooth, Wi-Fi, data roaming, airplane mode, app uninstalls, power-off. On Work Profile policies the device-level ones hide — a container can't enforce them.
- Per-app restrictions — disable specific policy apps inside the zone, with bulk toggles and a live count.
Zones operate independently; overlapping fences all apply. On Android, the check
interval (1 / 5 / 15 / 30 minutes, default 15) sets the responsiveness-vs-battery
trade — and alerts land as IN_FENCE / OUT_FENCE events on the Alerts page.
Safe Drive: the fleet-safety close
Safe Drive locks a moving device so drivers can't use it. It has three hard prerequisites, and quoting them correctly avoids a failed pilot: the policy must be Android Kiosk (any OEM kiosk variant counts), Location Tracking must be on in the same policy (speed comes from GPS), and the plan must include the feature.
Configuration is four decisions:
- Speed threshold — 10–160, in MPH or KMPH; the sustained speed that triggers the lock.
- Activation delay — minutes above threshold before locking.
0is instant; 1–2 minutes filters out brief spikes. - Override — let users unlock temporarily by picking a reason. Emergency is always present; add custom reasons (Co-Passenger, False Trigger…), and set the override duration after which the lock re-engages. Every override is logged for fleet audit.
- Whitelisted apps — navigation and dispatch tools that stay usable while locked. A whitelisted app can't be deleted from App Management until it leaves the whitelist.
Below threshold, the device returns to normal on its own.
Time fencing: policy that knows what time it is
Time Fencing schedules restriction windows per day of the week — start and end times with their own restriction toggles and an app allowlist during the window. Work-hours enforcement without anyone touching the console at 6 pm. It runs on the device's local time, which is the first thing to check when a customer says it fired at the wrong hour.
Compliance: the dimensions WeGuard watches
Compliance is the umbrella over all of it. WeGuard continuously evaluates devices on several dimensions: required apps installed, geofence position, data usage against Critical/Warning/Low thresholds, SIM events (removal, swap, insertion — the theft signals), password policy conformance, rooted or jailbroken state, baseline IT policy checks baked into QR enrollment, and time-fence adherence.
Violations surface in three places: the Alerts page (typed events like
SIM_REMOVED, ROOTED_ENROLL, DATA_USAGE), Reports → Device Compliance
(filter All / Compliant / Non-Compliant; export PDF, CSV, or Excel), and the
dashboard's non-compliant widget. When a device reads non-compliant but "looks
fine," check that it has actually synced the latest policy version and contacted
recently — stale devices report stale compliance.
That's the full arc of the course: pick the right type, run the lifecycle, know the catalog, lock down the endpoints that need it, and let location, time, and compliance rules do the enforcement you'd otherwise do by hand.