¶ 9. New policy
Application: Portal Nomid MDM
Document: V1.1.0
Last updated: 07/08/2026
Editorial owner: Nomid MDM Documentation
Last editorial review: 07/08/2026
Editorial language: en-US
The New policy wizard creates the initial configuration for an Android or VR/Pico policy. It organizes the name, group, device type, template, applications, and essential options before opening the full policy for review.
Important: Templates and quick settings are starting points. Before using a policy in production, review every section, save only after that review, and validate the result with a pilot group.
¶ Prerequisites
- Define the purpose of the policy and the type of equipment it will manage.
- Confirm the company and group where the policy should be organized.
- For Android, confirm that Android Enterprise and application sources are available.
- For VR/Pico, prepare the APKs and applications to be distributed.
- Avoid generic names; identify the role, audience, or operational purpose.
¶ Open the wizard
¶ From the Policies menu
Open Policies in the side menu and select New policy. Use this route when the task starts from policy administration.
¶ From the global shortcut
Open the global + button and select Create new policy. The interface may also display the corresponding keyboard shortcut.
¶ From the page button
On the policies page, select New policy to start the same wizard.
¶ Set the name, group, and device type
The first step identifies the policy and determines which set of settings is displayed.
¶ Name and group
- Policy name: enter a short, recognizable name. The current screen displays a 20-character limit.
- Group: select an existing group or create a new one when required.
- Organization: groups make it easier to search, delegate, and separate customers, sites, projects, or scenarios.
Use a predictable pattern such as Role-Site or Customer-Use, respecting the limit shown by the portal.
¶ Android Policy
Select Android Policy for smartphones, tablets, and rugged devices managed through Android Enterprise.
¶ VR / Pico Policy
Select VR / Pico Policy for Pico virtual reality headsets and ecosystem-specific resources.
Attention: The selected type defines the available templates, applications, and settings. If it is wrong, return to the beginning instead of adapting an incompatible policy.
¶ Create an Android Policy
¶ Choose a starting template
A template applies an initial baseline for the selected scenario. Review every generated setting because the template name does not replace technical validation.
In addition to the presets, the Other options section lets you start from scratch or copy an existing policy. These alternatives are detailed after the scenario templates.
¶ Individual Device
Use for a device assigned to one user in a work or controlled individual-use scenario.
Applied result: starts with Play Store in allowlist mode, USB file transfer blocked, default permission policy set to Prompt, status reports enabled, and the system default launcher.
¶ Multi-User Device
Use for equipment shared by multiple users when the scenario requires login or operator switching.
Applied result: starts with Play Store in allowlist mode, account modification, factory reset, USB, and safe boot blocked, default permissions set to Grant, status reports enabled, and Nomid Launcher.
¶ Frontline Worker
Use as a starting point for field teams, drivers, and mobile employees.
Applied result: starts with Play Store in allowlist mode, account modification, factory reset, and safe boot blocked, debugging disabled, default permissions set to Grant, status reports enabled, and Nomid Launcher.
¶ Kiosk
Use for equipment dedicated to one purpose or application. Validate launcher behavior, navigation, kiosk exit, and administrative recovery before saving and testing.
Applied result: starts with Play Store in allowlist mode, factory reset, USB, and safe boot blocked, debugging disabled, default permissions set to Grant, status reports enabled, and Nomid Kiosk.
¶ Start from scratch
Creates a policy without a scenario preset. It is the most flexible option but requires every necessary area to be reviewed and configured.
Applied result: creates the policy without a restriction or app preset and keeps the system default launcher until you configure it manually.
¶ Copy existing policy
Select an existing policy as the baseline. Use this when the new configuration is a controlled variation while preserving the original policy.
Applied result: copies the full selected policy resource, including apps, restrictions, launcher, Play Store, Wi-Fi, and other settings, into a new policy. The source remains unchanged.
You can also duplicate a policy directly through its action:
Duplicate policy also creates a separate policy with the source's complete configuration and does not change the duplicated policy. In either path, treat the copy as a new configuration before it reaches devices.
After copying or duplicating, review each of these items: name and group; app list and modes; launcher, Play Store, and kiosk; Wi-Fi, APN, VPN, proxy, and certificates; managed configurations; remote access; contacts and schedules; enforcement and destructive actions. Confirm, replace, or rotate scenario-specific credentials and secrets before use.
¶ Add applications
The Add apps step lets you choose suggested applications, browse categories, and build the initial policy list.
¶ Application sources
Under Find More Apps, the portal may offer:
- Browse Play Store: searches Managed Google Play.
- Add by package name: adds an application by its Android package identifier.
- Nomid Store: uses applications available in the company's own library.
Confirm the application name, developer, and package name before adding it.
¶ Required or Available
- Required: the application is mandatory and management attempts to install it on compatible devices.
- Available: the application is available for user installation from the managed catalog, depending on management mode.
- Blocked: when available in the full editor, prevents the app from being used or installed.
- Kiosk: when available, pins the app as a kiosk/single-app experience. In VR policies, regular apps stay Required and the Nomid Settings app can switch between Required and Kiosk.
Use Required only for necessary applications because mandatory installations increase traffic, setup time, and the impact of package failures.
¶ Configure essential options
The wizard displays high-level Play Store, launcher, and Wi-Fi options. Other settings remain available in the full policy editor.
¶ Play Store mode
- Allowlist: only organization-approved applications can be installed.
- Blocklist: all applications are allowed except those explicitly blocked.
Allowlist provides greater control; Blocklist provides greater freedom and requires closer monitoring.
This is the same operational logic called Allow list and Deny list on the Apps screen of an already-created policy; only the wording differs between screens.
¶ Choose Launcher
- Nomid Launcher: a managed and customizable experience.
- Nomid Kiosk: a locked experience that can use multiple policy apps or a single app in the full editor.
- System Default: keeps the native Android experience.
Choose according to the equipment's purpose and validate Home behavior, navigation, and administrative recovery.
¶ Wi-Fi network
Enable Wi-Fi when you want to deliver an initial network with the policy. Enter the SSID, security type, and password.
Security: Use a network appropriate for managed equipment. Do not document passwords, and update the policy whenever network credentials change.
¶ Create a VR / Pico Policy
¶ Choose a starting template
VR templates provide starting points specific to Pico headsets.
¶ Education
Use for immersive learning experiences, classrooms, and training labs.
Applied result: creates a VR policy, blocks factory reset, enables the custom launcher/kiosk behavior for the headset, and turns on status reports.
¶ Industrial Training
Use for safety simulations and practical training in industrial scenarios.
Applied result: creates a VR policy, blocks factory reset, enables the custom launcher/kiosk behavior for the headset, and turns on status reports.
¶ Start from scratch
Creates a VR policy without a preset. Configure the required applications and behavior manually.
Applied result: creates the VR policy without an app or restriction preset, requiring manual configuration before saving and using it on devices.
¶ Copy existing policy
Use an existing VR policy as the starting point for a new variation.
Applied result: copies the full selected VR policy configuration, including apps, restrictions, and launcher/kiosk behavior, into a new policy. The source remains unchanged.
You can also duplicate a VR policy directly:
Duplicate policy creates another VR policy without changing the source. Also review APKs, versions, headset compatibility, launcher/kiosk, network, and any inherited credentials before saving the copy.
¶ Add VR applications
Select applications available in the company store or upload a new APK for the policy.
¶ Upload APK
The window accepts APK files. The current interface indicates a maximum size of 3 GB and allows multiple files to be selected. Confirm origin, signature, version, package name, and headset compatibility before upload.
¶ Required or Available
- Required: installs the application as a mandatory policy component.
- Available: makes the application available without forcing immediate installation.
¶ Edit the VR/Pico policy after creation
After selecting Create Policy, the full editor organizes the VR/Pico policy into collapsible sections. Expanding or collapsing a section changes only its presentation; use Save to create and distribute a revision.
¶ Content
- Upload app > Upload single: uploads one APK for inclusion in the policy.
- Upload app > Batch upload: uploads several APKs in one operation; each file is still processed and validated separately.
- Add from Library: reuses an app already registered for the company.
- Search / Filter: limits the visible results without removing content from the policy.
- List / Grid: changes only the editor view.
- Required: makes the app mandatory on assigned headsets.
- Available: makes the app available without forcing installation.
- Remove: removes the app from this policy after the revision is saved and synchronized.
Before replacing a version, verify package name, signature, version code, and Pico model compatibility.
¶ Remote Access
Remote Access enables the capability to launch remote sessions on compatible headsets. Enabling it does not immediately open a session; the headset must receive the policy, be online, and report the required capabilities. Disabling it prevents new sessions after synchronization.
¶ Launcher Experience
Launcher Experience defines how policy apps are presented in the headset. Changes affect initial navigation and must be tested on a real headset. Collapsing the section does not disable the launcher.
¶ Network
- Add network: creates another Wi-Fi configuration.
- SSID: sets the exact network name, up to 32 characters.
- Open: configures a network without a password and should be limited to controlled environments.
- WPA2 / WPA3: requires a compatible protected network and password.
- Show/hide password: changes only field visibility in the portal.
- Expand/Collapse: opens or closes that network's fields without changing it.
- Remove: deletes the network from the next policy revision; confirm another connection remains available.
An incorrect password or removal of the only known network can leave the headset unable to receive the correction. Always test on a pilot.
¶ Security
Allow user factory reset determines whether the user can factory-reset the headset. Enabling it supports local recovery but allows management and content to be erased; disabling it reduces that risk and requires an administrative recovery process. Debug or development controls not visible in the interface are not part of the user flow.
¶ History
History shows recorded policy revisions for review and audit. Opening a revision helps identify what was configured at that time; it does not prove that every headset has synchronized. Validate each device's policy version and last communication.
¶ Editor actions
- Save: records a revision and starts asynchronous synchronization for assigned headsets.
- Duplicate policy: creates a separate policy and leaves the source unchanged.
- Delete policy: removes the policy from the active list; reassign devices first.
- See devices with policy: opens the assigned-device drawer for review and compatible actions.
- Provision device(s) with policy: starts a new provisioning flow with this policy.
¶ Before creating the policy
- Review the name, group, and device type.
- Confirm that the template matches the actual scenario.
- Remove applications added by mistake.
- Check the Required/Available mode of each application.
- For Android, review Play Store, launcher, and Wi-Fi.
- For VR, validate APKs, versions, and headset compatibility.
- If you are only exploring the wizard, leave without creating an unnecessary policy.
After selecting Create Policy, open the new policy and review every tab before assigning it to production devices. Creation saves the new policy; later changes also create the current revision and start its distribution, with no separate draft and publish stage.
¶ Validate the policy
- Confirm that it appears under Policies in the correct group.
- Review the summary, device type, applications, and initial settings.
- Save changes only after review, because saving creates the current revision and starts its distribution.
- Apply it to a compatible pilot device.
- Check application installation, launcher, network, restrictions, and synchronization; in Devices > Policy, confirm Policy version and Last sync.
- Record relevant changes in the description or the team's change process.
¶ Common issues
¶ Incorrect name or group
- Correct the information before distributing the policy.
- Avoid creating copies only to adjust naming when the policy is not yet in use.
- Confirm the company before completing the wizard.
¶ Incorrect device type
- Return to the beginning and create the policy using the correct type.
- Do not use an Android Policy for VR/Pico or a VR/Pico Policy for standard Android devices.
¶ The application does not appear
- Check Managed Google Play integration, package name, and availability for the country and company.
- For VR, confirm that the APK was uploaded and processed correctly.
- Review search filters and categories.
¶ Wi-Fi does not connect
- Confirm the SSID, security type, and password.
- Check that the network is in range and does not depend on a captive portal incompatible with enrollment.
- Update the policy when network credentials change.
¶ The copy brought unwanted settings
- Review every tab of the cloned policy, not only the initial wizard.
- Change the name, group, applications, networks, launcher, restrictions, and references from the original scenario.
- Test on a pilot device before replacing an existing policy.