Access is organised at two levels. Within the organisation, each user holds a role that defines the reach of their actions, from account owner down to read-only access. Alongside those roles sits a more granular control per resource and action, for cases where the default roles are too broad.
— Owner — full control of the organisation, including billing and team.
— Admin — full operational management.
— Operator — day-to-day operations.
— Read-only — lookup, with no ability to change anything.
Email verification is mandatory at sign-up, and access to capabilities is also bounded by the purchased plan — a capability not included in the plan is blocked server-side, not merely hidden in the interface.
Data isolation and audit
Each organisation is an isolated tenant, and the organisation identifier is enforced on database queries, so data from different organisations does not mix on shared infrastructure.
Every relevant action is written to an immutable audit log, capturing the action performed, the resource affected, the details, the IP address and the user agent. When Zonix EM support needs to access an account to diagnose a problem, that access uses a token with an expiry and is likewise recorded in the audit trail.
Sensitive secrets, such as Azure integration credentials, are stored encrypted.
Information needed from the product owner
Third-party audited certifications such as SOC 2 Type II and ISO 27001 have not been completed yet and sit on the roadmap. Timelines and scope for those certifications depend on a decision from the owner — do not publish estimates before that.
Diagnostic path
Most reported problems fall into a small number of causes. This path follows the order that tends to resolve fastest.
— Device or policy operations failing on a new account: check that the Android Enterprise enterprise is linked to the organisation. Without that link, those operations are refused.
— Enrollment QR Code that stopped working: check the token validity, which is 24 hours by default, and generate a new one if needed.
— BYOD or COPE enrollment refused: the work profile capability has to be available on the purchased plan.
— Command stuck as pending: the device has to be reachable to receive the action. Commands have a deadline and may expire before the device communicates again.
— Device state out of date in the console: state arrives by notification, not by live query. An offline device keeps its last known state.
— Device flagged as non-compliant: the compliance tab shows the source and reason for each finding, including those detected by behavioural monitoring alongside those reported by AMAPI.
When to open a ticket
If the path above did not resolve it, support can diagnose faster with three pieces of information: the device identifier, the approximate time the problem occurred, and what you expected instead of the observed behaviour. If the problem involves a specific command, saying which command and when it was sent helps locate the matching record.