Enrollment is the step where a device becomes managed. Choosing the mode is the most consequential decision in the process, because it defines what the organisation can and cannot do on the device — and changing mode later generally requires resetting the device.
— FULLY_MANAGED — corporate device, fully managed by the organisation.
— DEDICATED — single-purpose device locked to one app or a set of apps (kiosk).
— COPE — corporate device with a separate personal profile for the user.
— BYOD — the user’s own device, with a work profile isolated from the personal space.
BYOD and COPE depend on the work profile capability being enabled on the purchased plan. When it is not, token creation is refused with an explicit message, rather than issuing a token that would fail on the device.
Provisioning methods
The enrollment token can reach the device in more than one way. QR Code is the most used path: the platform generates the image as PNG or SVG, and the freshly reset device scans it from the welcome screen.
You can also issue single-use tokens, set the validity duration, and attach additional data and Wi-Fi configuration to the token so the device joins the right network during provisioning.
— QR Code generated by the platform, as PNG or SVG.
— Single-use tokens with configurable validity (24 hours by default).
— Wi-Fi configuration embedded in the token, to provision without a pre-existing network.
— Web tokens, for browser-driven enrollment flows.
— Zero-Touch and Samsung Knox, for corporate provisioning at scale.
Information needed from the product owner
The exact coverage level of Zero-Touch and Samsung Knox needs to be confirmed by the product owner before we document a step-by-step for these two methods here.
Policies
A policy is the set of rules applied to one or more devices. The platform builds the policy from the management mode you choose and lets you adjust each area from that baseline, instead of requiring you to assemble a configuration document from scratch.
— App management: install, restrict and push managed configuration to apps.
— Device passcode and encryption.
— Network: Wi-Fi and mobile data.
— System updates, with maintenance windows so reboots do not land during operating hours.
— Hardware and system restrictions: camera, USB, developer options and factory reset.
— Compliance rules, which flag a device as non-compliant when a condition is not met.
— Per-device policy, for when one device needs to diverge from its group.
Kiosk, work hours and inventory checkout
Beyond AMAPI policies, the Zonix EM Agent provides capabilities aimed at field and store operations that are not part of standard Android Enterprise.
The launcher policy defines a controlled home screen, in kiosk or standard mode, with your own visual identity: colour, logo, wallpaper, icon grid and app dock. You can control what appears in the interface (clock, date, status bar, navigation bar) and protect exit from kiosk mode with a PIN, as well as lock the power button, the settings and notifications.
Inventory checkout turns the device into a terminal for checking equipment in and out, with PIN or biometric authentication. Each session carries a state — active, returned, overdue or force-ended — and can be tied to the employee’s work hours record.
— Geofences triggering on entry, exit or both, with the resulting events recorded.
— Location history, both on explicit request and reported by the agent.
— Clock-in and work hours, including breaks.
Remote commands
Commands are actions run on the device from the console. All of them are written to the audit trail, with actor, resource and outcome.
— Lock the device immediately.
— Force a passcode reset.
— Reboot.
— Wipe the device (factory reset), optionally including external storage.
— Clear the data of a specific app.
— Start and stop lost mode, with a custom on-screen message and tracking enabled.
— Relinquish ownership, removing the device from management.
Commands are not instantaneous: they follow a lifecycle (pending, acknowledged, in progress, completed, failed or expired) and depend on the device being reachable. Commands sent to the agent arrive by push, which cuts latency, but an offline device only receives the action once it communicates again — and the command may expire before that happens.