Users and provisioning

Users in Airentect are directory entries that prompts and devices attach to. Provisioning controls who can create one, the seat cap controls how many you pay for, and groups decide which policy applies to whom.

How users are created

There are two paths into the directory:

• Admin-created. You add a person under Users and, for direct installs, generate their personal install link from their entry.
• Auto-provisioned on managed enrolment. When a managed device enrols with a deploy token and the browser knows the signed-in email, a directory user is created for that email automatically. This is what makes fleet rollout zero-touch.

Devices that enrol without a known email are not lost. They appear as anonymous "Managed device" entries under Endpoints, which you can rename or assign, and they re-map automatically once an email becomes known for that device.

Approved domains

User provisioning has two modes:

• Any. The default. Any device presenting a valid deploy token can enrol and auto-provision a user, whatever the signed-in email is.
• Approved domains. Enrolment only auto-provisions users whose sign-in email is on your approved domain list. Everything else is refused with a 403 and no API key is issued.

Switch to approved domains before any broad rollout. It closes two real gaps at once: an employee signed into a personal account on a managed browser cannot enrol that identity, and a deploy token that leaks outside your organisation is useless to whoever finds it, because their email domain will not pass the gate. The deploy token is deliberately low-privilege on its own; the domain gate is what binds it to your organisation.

The gate is enforced server-side at the gateway during enrolment, not in the browser, so it cannot be bypassed by a modified client.

Warning: Devices with no signed-in email still enrol as anonymous managed devices under approved domains mode. The gate rejects wrong-domain emails; it does not reject the absence of one. If you see anonymous entries piling up after a rollout, fix identity mapping on those devices rather than assuming the gate failed.

Seat limits

Your organisation may carry a user cap. Two things matter about how it is counted:

• Seats are distinct directory users, not devices. One person enrolled on a laptop and a desktop is one seat. You never pay twice because someone has two machines.
• Anonymous managed devices count. An anonymous enrolment creates a directory identity, so it occupies a seat until it re-maps to a real user. Another reason to get email mapping right early.

When the cap is reached, enrolment of a new user is refused; existing users and their devices keep working. If enrolments start failing during a rollout wave, check the seat count before debugging anything else.

Groups and policy assignment

Groups exist to drive policy. The default policy covers everyone; a group policy applies to exactly the users in its assigned groups. Manage membership under Users, and assign policies to groups on each policy's Assignment tab.

When a user seems to get the wrong enforcement, trace it in this order: which groups they are in, which policies are assigned to those groups, and only then what those policies contain. Most "the policy is not working" reports are assignment gaps, not policy bugs.