Nomid MDM MCP Server

Propose creating a new policy, optionally with setting changes. With fromPolicyId it is a copy (duplicate) of that policy - its apps, settings and restrictions. Without it, it is a new policy from scratch with Nomid's defaults (the Nomid Settings agent, device reporting, Play Protect enforced, the standard Android home screen, no other apps), in the default group. When the user asks for a new policy without naming one to copy, create it from scratch; do not pick a policy to copy for them. Before a policy from scratch, unless the user already said what it is for or what it needs, or asked for it to be created right away, ask what the policy is for (which devices, used by whom, for what); then, only for what matters for that use and was not answered yet, ask once more in a few short questions: one app in kiosk mode or several apps, which apps or websites, Wi-Fi, and what to lock down (camera, USB, factory reset, Play Store). Then propose it with the settings that follow, and its apps once it exists. Once it exists, add apps with propose_policy_change with apps and set Wi-Fi and anything else with propose_policy_change with edits; once its apps are in, turn kiosk mode on (or the launcher, with its dock) with propose_policy_change with homeScreen. Nothing is created yet: this returns a proposal with the change list. Show it to the user and get their explicit approval. No device uses the new policy until one is moved to it (send_device_command with command change_device_policy). Once the user approves, apply it with apply_policy_proposal (a person approves a HIGH impact one in the Nomid portal instead: give the user its approvalUrl).

Get a policy's full configuration as JSON, or the part at a path: Wi-Fi networks (openNetworkConfigurations), passwords, restrictions, system updates, the launcher, time and geo fences, app configurations and everything else. Secrets read as {"redacted": true}. Use it before propose_policy_change with edits, for anything get_policy_settings doesn't list. Without a path, apps are summarized: read /apps/<packageName> for one app's configuration. lockedFields lists what agents can't change. version (the portal's number) and changedAt say when the policy was last saved.

Get a policy change proposal you made, by its proposalId: its change list, impact, status (PENDING, SUCCEEDED, FAILED, EXPIRED, ...), expiry and outcome. Once SUCCEEDED, result carries what applying it returned (for create_policy, the new policyId and version).

Read a policy's saved historical configuration by revision ID from list_policy_revisions, with secrets replaced by {"redacted": true}. Returns the revision's policy version, providerVersion when recorded, save time and recorded audit actor. These describe saved configuration, never proof that a device applied it or that a person manually made the change. Read-only: creates no proposal and restores nothing. Use get_policy_document for the current configuration. A large result comes in parts: notShown lists paths to read separately, and nextFromIndex continues the same path. path is a JSON Pointer with numeric array indexes; omit it for all fields including apps. The current policy group is excluded because it is not historical configuration.

Get the settings of a policy that AI agents can change: for each one its id, label, group, current value, allowed values and whether changing it is high impact; plus the policy's version (the portal's number; every save raises it) and changedAt (when it was last saved), deviceCount and apps (package name, name, source, install type). Values: NOT_SET means left to the device or Google's default, CUSTOM a portal value these values cannot express. Read this before proposing changes with propose_policy_change with settings, propose_policy_change with apps or create_policy. Everything else in a policy is read with get_policy_document.

List the saved revisions of a policy, newest first: revision number, when and by whom it was saved, and the policy version it produced. changedBy is recorded audit attribution, not proof of a manual human action. Read a saved configuration with get_policy_revision_document; saved versions do not prove a device applied them. Use rollback_policy only to propose a restore.

Get full details for a single device (asset) in the authenticated company by its path name, including policy assignment, custom data, tags, hardware specifications and last known location. Its "lastSync" is the portal's "Last sync" (last contact); "syncedAt" is only the last status report. managedDevice.policyVersion is the current version of the device's policy, the number the portal and policy reads show; whether the device applied it is diagnose's (area policy_sync) to say. Returns a tool error if no device with that id exists in this company.

Get the apps actually on one device (asset) in the authenticated company, from the app report the device last sent: package name, app name, version, state (INSTALLED, or REMOVED when it was uninstalled), installedBy (POLICY, USER, SYSTEM = came with the device) and source. Use it to answer "is app X installed / which version", to check whether a policy app reached the device, and to find the package name of an app that came with the device (e.g. the manufacturer's Phone, Camera or Gallery app) instead of asking the user for it: search by name with query. Without a query, system apps are left out (systemAppsHidden counts them) unless includeSystemApps is true. The list is as of reportedAt, not live; an app installed since then appears after the next status report. Being in the policy does not mean an app is on the device: check here. Returns a tool error if no asset with that id exists in this company.

Get the most recent commands sent to a device (asset) in the authenticated company, newest first: type, status, timestamps, a short outcome code and who sent it. requestedByType USER means a portal user, named in requestedBy by email (also when Nomid Agent sent it for them; SUPPORT is Nomid or partner support); API_KEY means an integration, named by the key's name. No requestedBy means no person or key was recorded: Nomid itself (a policy change, an automation), the device, or a command sent before this was recorded; never guess who it was. When Google said why a command failed, reason carries it: RESET_PASSWORD_RECENTLY means lost mode was refused because the device's password was reset shortly before (Android blocks lost mode for a while after a reset; try again later without resetting it again), USER_EXIT_LOST_MODE_RECENTLY that the user recently left lost mode, ALREADY_IN_LOST_MODE / NOT_IN_LOST_MODE that the device was already in / not in lost mode. Command payloads and any sensitive data (e.g. passwords) are never included. Returns a tool error if no asset with that id exists in this company.

Get who logged in on the company's devices: the sessions of device users, newest first. Each has the device user (name, auth PIN, SSO or EXTERNAL = authenticated by the customer's own system, and that system's externalUserId), the asset (assetId, serial number, name), loginAt, logoutAt, expiresAt, open, and who reported the login and the logout: DEVICE (the Nomid agent on the device), API (the customer's system, through the Public API) or EXPIRY (the session expired). Use it for "who is using device X", "who used it on a date", "where is user Y logged in". Filter by asset (assetId or serialNumber), by user (deviceUserId or externalUserId), by open, and by when the session started (from, to); every filter is optional. An asset's sessions include those of earlier enrollments of the same hardware. Returns a tool error if no asset with that id or serial number exists in this company.

Nomid staff only (Nomid system admins; refused for everyone else). Reads one device's stored documents as they are in the database, every field included: asset (with asset.managedDevice, the device as last reported: appsReport with each app's keyedAppStates, events, hardware, network, memory and power events, non-compliance) and currentStatus (the agent's reports: nomidApps, checkups, appMetadata, battery, screen, foreground app, last location). Use packageName for one app's report and keyed states. A document too large for one result comes in parts: value has what fits, notShown lists what needs its own call with its path, and when nextFromIndex is present call again with fromIndex = nextFromIndex. Values that are secrets are replaced by {"redacted": true}, and so is an install error's raw body (installErrorCode stays). Use company to name the company; another customer's device needs an "All Nomid customers" connection. Prefer get_device or diagnose unless you need a field they omit.

The company's own Nomid plan (FREE, PRO or ENTERPRISE), its term and billing cadence, its device limit (the Free plan's; paid plans have none), how many devices count as billable now and which devices count, and whether anything blocks new enrollments. The device limit never blocks enrollment: devices above it still enroll and count. Use it before any claim about this company's plan, limit or billable devices. No prices: for list prices use search_nomid_site; the company's invoices are on the Billing page (portalUrl).

Nomid staff only (Nomid system admins; refused for everyone else). Lists one company's portal AI chat conversations, reviewed or not, most recently active first (default: the last 7 days), each with its sessionId, title and dates. Use company to name the company; another customer's needs an "All Nomid customers" connection. Pass a sessionId to read that conversation (a long one comes in parts: pass nextFromTurn as fromTurn): every turn's text, the tools the agent called with their status and input summary, proposals with their live outcome, and the user's feedback. Text is redacted (emails, company names, secrets) and the user is not identified; tool results are not stored, so they are not shown. Conversations the user deleted are never returned. Only chats active in the last 30 days.

Send one command that cannot be undone to one real, physical device, the command chosen with command; these are never sent to several devices at once. It runs immediately, with no approval step in Nomid: before calling it, tell the user exactly what it does to which device and get an explicit yes, and never resend one after an unconfirmed result without asking. assetId is the device's pathName from search_devices or get_device. A command's own arguments are named in its line, and passing another command's argument is an error. Returns a tool error if no device with that assetId exists in this company or its status or device type does not allow the command. Needs the destructive device command permission and the company's destructive commands opt-in (clear_app_data: the device command permission). Commands: - wipe_device: Destructive. Remove it from management and erase its managed data: a factory reset on a company-owned device, the work profile on a personal one. Irreversible. - reset_screen_lock: Destructive. Remove its screen lock (PIN, pattern or password), Android Management only. - change_screen_lock_password: Set newPassword (the password the user chose; ask for it, never invent one) as its screen lock password, Android Management only: it locks and only the new password unlocks it. - relinquish_ownership: Destructive. Release a company-owned device to its user: the work profile and its data are removed and it is no longer managed. Irreversible. - uninstall_apps: Destructive. Uninstall the apps in packageNames with their data (AOSP/PICO, Nomid agent 4.5.20 or later), never the Nomid agent. It runs when the device next checks in, even days later: follow it with list_device_commands. An app its policy installs comes back on the next sync: to keep it off, block it in the policy. - clear_app_data: Erase all data of the apps in packageNames (accounts, settings, files), Android Management only. Cannot be undone.

Send one command to real, physical devices, the command chosen with command: one device (assetId, its pathName from search_devices or get_device), several (assetIds, up to 50 pathNames) or every device of a policy that can take commands (devicesInPolicy, its pathName from list_policies; at most 50). For several devices make one call with all of them, never one call per device. It runs immediately: confirm intent with the user before calling it, naming how many devices, and never resend one after an unconfirmed result without asking the user first. A command's own arguments are named in its line, and passing another command's argument is an error. Returns a tool error if no device with that assetId exists in this company or its status or device type does not allow the command. On several devices, a device that cannot take it does not stop the others: the result lists each device's outcome (SENT, NOT_SENT and safe to retry with retryAssetIds, UNCONFIRMED, FAILED). Needs the device command permission (change_device_policy also the policy read permission). The result says whether the device confirmed it; follow it with list_device_commands. Commands: - lock_device: Lock its screen now; the user unlocks it again normally. - start_lost_mode: Lock it and show message (required) and the optional phoneNumber, email, streetAddress and organization on its lock screen. Undo with stop_lost_mode. - stop_lost_mode: End lost mode (the device was found). Nothing happens if it was not in lost mode. - send_device_message: Show a notification with title and body (both required) on it. Each call sends another one. - request_status_report: Ask it for a fresh status report (battery, network, apps, security); it arrives shortly, read it with get_device. - force_location_update: Ask it to report its location now; read it afterwards with get_device. - sync_policy: Send it its current policy again. Nomid agent (AOSP) devices only: Android Management devices get policy changes by themselves. - reboot_device: Restart it now; interrupts whoever is using it. - shutdown_device: Power it off (AOSP only). Someone has to turn it on again by hand. - launch_app: Open the installed app packageName on it (AOSP only). - change_device_policy: Move it to the policy policyId (pathName from list_policies): it applies that policy's apps and settings and loses what only the current one had. Name both policies.

Find where an app is, by package name or by name, in one call: whether it is in a policy (its source - Google Play, the Nomid Store Library, a secure web app - its install type and whether it is the kiosk app), in the company's Library, on Google Play (by package name only) and installed on a device (from its last app report). Pass policyId, assetId or both; with assetId alone the device's own policy is checked. "answer" sums it up, and says how the app can be added. Call it before saying an app is or is not somewhere, before adding one, and again whenever the user says an app is there after all: policies and devices change during a conversation. A place this caller cannot read says notChecked: that is not "not there".

Apply a policy change you proposed (propose_policy_change, create_policy, rollback_policy) by its proposalId. Only call this after showing the user the proposal's change list and getting their explicit approval in this conversation. A HIGH impact proposal can't be applied here: a person approves it in the Nomid portal, so give the user its approvalUrl, and get_policy_proposal then shows the outcome. Fails without changing anything if the proposal expired, was already applied, or the policy was changed since it was proposed (stale_proposal: read it again and propose again).

List the companies this connection can work in, each with its `company` value, tenant and device counts (total, by status, and ACTIVE devices with no check-in for 7 days or more), plus totals across every listed company. Use it to answer questions about the whole fleet across companies, or to find a company, then pass its `company` value as the company argument of any other tool to work in it. A connection made for one company (or an API key) lists only that company.

Count the authenticated company's devices, optionally narrowed by device status, assigned policy (or several, with "policies"), "lastSyncBefore" (each device's last sync, the portal's "Last sync", before an instant: use it for devices not synced, not seen or offline since a date), "lastSeenBefore" (asset record updated before an instant; not proof of being offline) and/or "missing" (devices without an IMEI or a serial number, e.g. "how many devices have no IMEI"). Use this instead of search_devices when only a total is needed, e.g. "how many active devices do we have" or "how many devices have not synced in a week". With "groupBy" it breaks the count down by "policy", "model" and/or "status" in one call, exact for the whole fleet: use it for which models are in a policy, how many of each model, or each model per policy, never search_devices, whose results are capped.

Search the authenticated company's device fleet. Devices are returned as "assets" - the business-level representation of an enrolled or tracked device, including its policy assignment, custom data, tags, hardware specifications and last known location. Results are paginated; use "page" and "size" to page through a large fleet. Optionally narrow the search by device status, assigned policy, "lastSyncBefore" (each device's "lastSync", the portal's "Last sync", before an instant: use it for devices not synced, not seen or offline since a date; "syncedAt" is only the last status report), "lastSeenBefore" (asset record updated before an instant; not proof of being offline) and/or "missing" (devices without an IMEI or a serial number; count_devices counts them). To find a device the user names, use "query" alone (name, serial number, IMEI, model or tag): it returns up to "size" best matches, each with its "pathName" and the field that matched, instead of a page of assets. When no managed device matches, the query also looks at devices removed from management, returned with status DELETED, as a wipe or removal leaves them. To list which devices match filters (for example every device not synced since a date), pass fields "names": a table of each device's name, pathName, policy and lastSync, up to 200 a page, with the exact total and the next page, instead of 25 full devices.

Diagnose a problem in one call, the problem chosen with area. Run it before guessing a cause. For enrollment, inspect current saved defaults and recent QR options, including offline and mobile-data flags, before attributing a failure to Wi-Fi. Saved QR options do not identify the QR scanned or prove live Google state. remote_access, policy_sync (one device, by assetId): Diagnose a problem area on one device (asset) of the authenticated company in a single call. area "remote_access" explains why the device cannot be reached or controlled remotely: device sync and status, whether its policy includes NomidRemote and its relevant settings, whether NomidRemote is installed and up to date, whether its service is checking in and can capture the screen and take input, and the recent remote-access requests and sessions with how they ended: the outcome the portal recorded for each request (connected, offline, timeout, password_wrong, rejected, cancelled, ...) and the diagnostic events NomidRemote reported around it (service stops, lost connection to the remote-access server, network changes, relay failures, with battery and network context). area "policy_sync" explains why a device or a feature on it does not work as configured (settings or apps not applied, screen preview or classroom mode showing no image): whether the device synced recently, whether it applied the current version of its policy, whether the policy's required apps are installed or failed to download, whether the Nomid agent is up to date, and its screenshot state (the newest screenshot, and whether recent screenshot requests were answered, answered without an image, failed or never answered). Returns "findings" (likely causes, most likely first, each with evidence and a next step) and "unknowns" (what could not be determined, to ask the user about). Never returns credentials, keys, remote-access ids, screenshot images or their URLs. Returns a tool error if no device with that id exists in this company. enrollment (devices that fail to enroll with a QR code): Diagnose why Android devices fail to enroll (provision) into this company with a QR code, in one call. Check current saved provisioning defaults and bounded recent saved QR options first: allowOffline, useMobileData, whether defaults select Wi-Fi, and whether a saved QR link would embed Wi-Fi now. A selected network may still be too large to fit in a QR. A device may join Wi-Fi manually, and company Wi-Fi settings do not prove the scanned QR embedded it. This also checks saved QR Wi-Fi format (never the password), whether Android Enterprise is linked, the policy and its enrollment tokens, whether the device (by serial number) ever reached Google, and devices stuck in setup. Returns "findings" (likely causes, most likely first, each with evidence and a next step), "unknowns" (what to ask the user) and "deviceChecks" (what only the person holding the device can check). Saved options do not identify the QR actually scanned, validate Google live, or reveal the exact device error. Ask for the error, attempt time, device model and network used when needed.

Nomid staff only (Nomid system admins; refused for everyone else). Lists the reviews of portal AI chat conversations, newest first (default: FLAGGED in the last 7 days), each with its company, severity, signals, failure categories, the reviewer's summary and humanOffer (the "Talk to a human" offer the chat showed the user: SHOWN, ACCEPTED, DISMISSED or null). Pass a reviewId to read that review's conversation (a long one comes in parts: pass nextFromTurn as fromTurn): every turn's text, the tools the agent called with their status and input summary, proposals with their live outcome, and the user's feedback. Text is redacted (emails, company names, secrets); tool results are not stored, so they are not shown. Only reviews from the last 30 days.

Get a compact aggregate summary of the authenticated company's fleet: total device count, a breakdown by status, and the security-posture summary (secure/at-risk/compromised/unknown counts, encryption/ADB/unknown-sources/dev-settings counts, and up to 10 risky device path names). Never returns a full device list - use search_devices for that.

Search the company's Nomid Library: its apps (private Android apps uploaded to Nomid, with package name, version and categories) or, with kind "links", its web links (VR library). Returns how many the Library has, how many match and the matches, each app with its portal link. Only the Library: an app from Google Play or one a policy installs is not here (read the policy with get_policy_settings), nor what a device has installed (list_device_apps), so "not in the Library" never means "not on the devices".

Search Nomid's public website (www.nomidmdm.com) for plans and pricing: the Free, Pro and Enterprise plans and their device limits, list prices per Android and VR device per month in USD, EUR and BRL, the annual discount, what each plan includes (e.g. remote access and the API are paid), and the pricing FAQ (payment methods, plan changes, pilots, custom plans). Returns excerpts with their page URL to cite. These are public list prices, not this company's own contract or invoice. For how to use a product feature, use the documentation search instead.

List every policy defined in the authenticated company, or with query those matching it, with overview information (path name, display name, description, version, policy group, deviceCount). deviceCount is the number of devices on the policy (0 when none), not counting deleted or reprovisioned ones. Configuration detail of each policy is excluded: read one policy's with get_policy_document or get_policy_settings.

Get the URL of a device, policy or library app in the Nomid portal, to show the user where to see or manage it, or of a fixed portal page (kind "page": the dashboard, the devices or policies list, the library, enrollment, a company settings tab such as users, billing or ai_agents, an integration such as android_enterprise or sso). Needs the id of the object (the "pathName" of an asset or policy, an app's package name, or the page's key). Returns a tool error if the object does not exist in this company or is not visible to the caller, or if the signed-in user may not open the page; the link only opens the page, the portal still applies the signed-in user's own permissions.

Propose one change to an existing policy: pass policyId and exactly one of the parts below; for changes of several kinds, call it once per part. Parts: settings (the restrictions, security, connectivity, location, reporting and Play Store settings get_policy_settings lists); apps (add, remove or change how apps are installed); homeScreen (kiosk mode, the Nomid launcher or the device's own home screen, and the dock); details (the description, tags or policy group); edits (anything else, such as Wi-Fi, passwords or fences, as JSON Pointer edits of get_policy_document). settings: Propose changing settings of an existing policy (restrictions, security, connectivity, location, reporting, Play Store mode). Nothing changes yet: this returns a proposal with the change list (current -> new value), the number of devices on the policy and its impact. Show the change list to the user and get their explicit approval. Read get_policy_settings first for the ids, current and allowed values. Change only the settings the user asked for: one setting can cover several words of the request (DEVELOPER_SETTINGS is developer options and USB debugging), and a setting with a similar name is not part of it (USB_DATA_ACCESS is file transfer over USB, not debugging). Apps are changed with the apps part; Wi-Fi and other networks, fences, the launcher look and everything else with the edits part. apps: Propose adding apps to an existing policy (a Google Play or Nomid Store app by package name, or a Nomid secure web app for a URL), removing them, or changing how they are installed. Nothing changes yet: this returns a proposal with the change list, the number of devices on the policy and its impact. Show it to the user and get their explicit approval. find_app says whether an app is already in the policy, in the Library, on Google Play or installed on a device; get_policy_settings lists the policy's apps. Nomid's own apps and the kiosk app can't be changed here, nor can an app be made the kiosk app: kiosk mode, the kiosk app and the dock are set with the homeScreen part. In a kiosk that opens a single app, an added app is installed but not shown. homeScreen: Propose switching the home screen of an existing policy, as the portal's Launcher section does: kiosk mode on or off (Nomid Kiosk, multi-app or locked to a single app), the Nomid launcher, or the device's own home screen, and which apps sit in the launcher's dock. Nothing changes yet: this returns a proposal with the change list, the number of devices on the policy and its impact (HIGH whenever devices are on it). Show it to the user and get their explicit approval. The Nomid launcher can also show the device's own built-in apps (addSystemApps: PHONE, CONTACTS, CAMERA, MESSAGES, SETTINGS, BROWSER), which open whatever app fills that role on the device: this is how a preinstalled dialer or contacts app that isn't on Google Play gets on the home screen, with no package name. Nomid Kiosk doesn't offer them: it opens only the policy's own apps. Which other installed apps the launcher and the multi-app kiosk also show is appsOutsidePolicy (by default every installed app, preinstalled ones included): only when the user says the kiosk or launcher shows apps they didn't choose, or asks to hide or show such apps, propose the current mode with appsOutsidePolicy POLICY_ONLY; on any other change leave it out. The kiosk app and the other dock apps must already be in the policy: add them with the apps part first, and propose this only once that change is applied (applied with apply_policy_proposal; never while it is still pending). Read the current mode with get_policy_document (its overview says it) before saying what the policy has. Once in kiosk, its controls (status bar, navigation buttons, power button, device settings) are edited with the edits part at /kioskCustomization. details: Propose changing how an existing policy is organized in the portal: its description, its tags or the policy group it belongs to. Devices are not affected. Nothing changes yet: this returns a proposal with the change list. Show it to the user and get their explicit approval. Tags replace the current list: read them with get_policy_document first and send the whole new list. A group must be one the user can move policies into; when it isn't, the answer names the groups they can use. edits: Propose changes to any editable part of an existing policy - Wi-Fi networks, password rules, restrictions, system updates, launcher look, time and geo fences, an app's managed configuration - as JSON Pointer edits of the document get_policy_document returns (read it first and follow its field names and shapes). Nothing changes yet: this returns a proposal with each field's old and new value, the number of devices on the policy and its impact. Show it to the user and get their explicit approval. Prefer the settings part for the settings get_policy_settings lists, and the apps part to add or remove apps, the homeScreen part to switch kiosk mode or the launcher, and the details part for the description, tags or group. Contact lists, library files and the VR environment are attached by id: read /phoneContacts, /libraryFiles or /vr with get_policy_document, pick from the items it lists under attachable, then append {"phoneContactsUuid": ...} to /phoneContacts/-, {"libraryFileUuid": ...} to /libraryFiles/- or SET /vr/pico/vrEnvironmentId; REMOVE detaches one. A Wi-Fi network is added by appending {"Name": ..., "Type": "WiFi", "WiFi": {"SSID": ..., "Security": "WPA-PSK" (or "None", "WEP-PSK"), "Passphrase": ..., "AutoConnect": true}} to /openNetworkConfigurations/NetworkConfigurations/-; ask the user for a password the network needs, never invent one. A field the document doesn't show yet can still be SET: an app becomes the always-on VPN with /alwaysOnVpn set to {"packageName": ..., "lockdownEnabled": false} (true blocks the network until the VPN connects), once the app is in the policy (add it with the apps part first, and propose this only once that change is applied: applied with apply_policy_proposal; never while it is still pending); /personalUsagePolicies/maxDaysWithWorkOff is how many days the work profile of a company-owned device can stay off; /shortSupportMessage/message (and /longSupportMessage/message) is the support message devices show where a setting is blocked by the policy. strongUnlock in a /passwordPolicies entry (e.g. /passwordPolicies/0/strongUnlock, the entry of the scope the user means) set to EVERY_DAY makes the device ask for the PIN, pattern or password at least once every 24 hours, so it can't keep unlocking with fingerprint or face alone; DEFAULT_DEVICE_TIMEOUT keeps the device's own default (72 hours on stock Android). A schedule (time fence) is appended to /timeFence/rules/- as {"packages": [...], "availabilities": [{"dayOfWeek": "MONDAY", "startOpen": "08:00", "endClosed": "18:00"}, ...]}: the apps open only inside those windows, and not at all on a day without one. Enum values are Nomid's names as get_policy_document shows them (DEVICE, EVERY_DAY), not Google's (SCOPE_DEVICE, REQUIRE_EVERY_DAY); a refusal lists the accepted ones. Once the user approves, apply it with apply_policy_proposal (a person approves a HIGH impact one in the Nomid portal instead: give the user its approvalUrl).

Create a QR code that enrolls a new or factory-reset Android device into this company under the given policy. Each call creates a new enrollment token that stops working 24 hours later, so create one only when the user asks for a QR code to enroll devices, and never reuse an older one. The QR image is delivered to the user directly with this result: do not describe, transcribe or rebuild it. To use it, tap the welcome screen of the device's setup wizard six times and scan the code. VR-only policies cannot be provisioned with a QR code.

Propose rolling a policy back to one of its revisions (list_policy_revisions): its whole configuration - apps, settings, restrictions, networks - is restored, and its name goes back to the revision's when they differ (the change list shows it); description, tags and group stay. Nothing changes yet: this returns a proposal with the differences. Show it to the user and get their explicit approval. A rollback of a policy that has devices is HIGH impact. Once the user approves, apply it with apply_policy_proposal (a person approves a HIGH impact one in the Nomid portal instead: give the user its approvalUrl).