¶ ¶ User Manual — Policies
Application or layer: Portal Nomid MDM
Document: V1.0.0
Last updated: 17/06/2026
Language: en_US
The Policies module is where the administrator defines how managed Android devices should behave. A policy can install applications, block system functions, configure networks, define launcher/kiosk, collect data, apply security rules, limit usage by time/location, and control device resources.
Important: Changing a policy may affect all devices associated with it. Before saving changes in production, review the scope, validate in a test group and monitor the application in Devices > Policy.
¶ ¶ List of policies
¶ ¶ List of policies
The list of policies in table format, with columns for name, version, apps and main settings.
This area is used to compare existing policies, check versions, identify which ones have kiosk, Wi‑Fi, APN, restrictions or other capabilities enabled.
¶ ¶ Featured elements
- Policy table: displays existing policies and their main attributes.
- Policy Name: opens the correct policy for review or editing.
- Version/status: indicates the maturity of the configuration and whether there is a published change.
- Feature indicators: quickly show whether you have apps, launcher, network, security, geofence, or collection configured.
- Line actions: give access to editing, duplication, publication or removal according to permission.
¶ ¶ Operational guidance
- Use the table to find the correct policy before editing. Click the name to open details or use contextual actions to duplicate, edit, publish or remove based on permissions.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Policy Grid
The grid/card view of policies.
This area is used to view policies as summary cards, useful for visual navigation and environments with fewer policies.
¶ ¶ Featured elements
- Policy Cards: present policies in visual format.
- Card Summary: shows identification, status and main features.
- Opening the card: takes you to the policy details for adjustments.
- Recommended use: facilitates navigation in environments with few policies or well-named policies.
¶ ¶ Operational guidance
- Switch to the grid when you want to quickly review cards. Open the desired policy card to view details, edit settings or confirm status/version.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Policy search and filters
The search area, filters and selection of policy views.
This area is used to find policies by name, status, group, integration, version, or specific characteristics without scrolling through the entire list.
¶ ¶ Featured elements
- Search field: locates policies by name or related term.
- Filters: reduce the list by status, group, integration or characteristic.
- View switching: switches between table and cards.
- Operational application: avoids duplicate creation and speeds up finding the correct policy.
¶ ¶ Operational guidance
- Enter a term in the search or apply filters. Use this before creating new policy to avoid duplication and to quickly find the policy applied to a given group of devices.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The home screen lists existing policies and allows you to switch between list or grid view.
¶ ¶ What is it for
- Find policies by name, status, group, integration or type.
- Compare policies used by different areas.
- Quickly see which policies are active, in draft or pending.
- Access the edition or summary of a policy.
¶ ¶ Search and filters
Use search to find policies by name. Use filters to narrow the view by status, integration, group, or other attributes available in the tenant.
¶ ¶ Actions, tabs and policy summary
¶ ¶ Policy actions
The actions menu within a policy page.
This area is used to perform policy operations, such as edit, duplicate, publish/apply new version, view linked devices or delete, according to portal rules.
¶ ¶ Featured elements
- Actions: brings together open policy operations.
- Edit: enables adjustments to the rules when the profile has permission.
- Duplicate: creates a safe copy for testing or variation by group.
- Publish/Apply: sends the new version to linked devices.
- Delete: removes unused configurations, requiring verification of the impact.
¶ ¶ Operational guidance
- Access the policy, click on Actions and choose the option. Before publishing changes, review impact on linked devices and record the change in the policy history or description.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Tabs and search
The tab bar and internal policy search.
This area is used to navigate between sections such as Basic, Apps, Launcher, Network, Configuration, Hardware, Security, Geofence, Timefence, Contacts, Collected Data and History.
¶ ¶ Featured elements
- Configuration tabs: separate Basic, Apps, Launcher, Network, Configuration, Hardware, Security and other areas.
- Internal search: finds specific fields within long policies.
- Section navigation: reduces error when editing different resources.
- Tab indicators: help you understand where there are completed or pending settings.
¶ ¶ Operational guidance
- Click on the desired tab or use the internal search to find a specific configuration. This path is faster when the policy has many sections and fields.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Policy Summary
The policy summary with general data and configuration indicators.
This area is used to quickly understand purpose, version, apps, linked devices, status, and key enabled features.
¶ ¶ Featured elements
- Name and description: identify the purpose of the policy.
- Status and version: indicate publication, draft or pending change.
- Linked devices: shows the size of the operational impact.
- Enabled features: summarize apps, launcher, network, security, collection and restrictions.
- Summary history: helps you understand recent changes before editing.
¶ ¶ Operational guidance
- Read the summary before editing. Use the indicators to confirm that the policy matches the objective, for example kiosk, data collection, app control, or network restriction.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
When opening a policy, the portal displays a summary and configuration tabs.
¶ ¶ Common actions
- Save: saves changes made to the policy.
- Duplicate policy: creates a copy for testing or variations per group.
- Delete policy: removes a policy that should no longer be used.
- Apply/Update Devices: triggers the update on linked devices, when available.
¶ ¶ Summary
The summary shows information such as policy name, identifiers, linked groups, number of devices, last change and application status.
Tip: Before editing, check whether the policy is associated with production devices. When possible, duplicate the policy and test on a smaller group.
¶ ¶ Basic
¶ ¶ Basic configuration
The basic policy tab, with identification and initial fields.
This area is used to configure name, description, group, usage mode and fundamental information that helps organize the ruleset.
¶ ¶ Featured elements
- Name: must indicate client, function, restriction or group served.
- Description: documents the policy objective for support and auditing.
- Group/scope: defines where the policy will be used.
- Configuration State: separates drafts from production-ready policies.
- Nomenclature: avoids incorrect application in production devices.
¶ ¶ Operational guidance
- Fill in a clear name, objective description and correct group. Use standardized nomenclature, such as client/role/constraint, to facilitate support and avoid applying the wrong policy.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Basic tab defines the fundamental data of the policy.
¶ ¶ Common fields and decisions
- Policy name: use clear names, such as “Kiosk - Logistics - Insurance”.
- Description: explain the objective of the policy and the target audience.
- Group/scope: define which devices or groups the policy will be used on.
- Status: Maintain separate drafts of active policies when flow permits.
¶ ¶ Good naming practice
Include purpose, group, and restriction level in the name. This avoids errors when changing policies on devices.
Examples:
Kiosk - Deliveries - ProductionMaintenance - Technical SupportBYOD - Work ProfileSchool Tablet - Teachers
¶ ¶ Applications
¶ ¶ Apps - quick setup
The main applications tab within the policy.
This area is used to define which apps will be installed, allowed, removed, hidden or configured on devices that receive the policy.
¶ ¶ Featured elements
- Application preset: applies initial combinations for common scenarios.
- Default installation: defines initial behavior of managed apps.
- Allowlist/block: guides which apps can appear or be used.
- Post review: is required to confirm package, version, permissions and managed configuration.
¶ ¶ Operational guidance
- Access Apps, add apps from Library/Managed Google Play and set installation behavior. Then review permissions, managed settings, and availability by device.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Apps - quick setup
The quick app settings area.
This area is used to apply configuration shortcuts to speed up common scenarios, such as releasing basic apps, preparing kiosks, or setting default installation behavior.
¶ ¶ Featured elements
- Application preset: applies initial combinations for common scenarios.
- Default installation: defines initial behavior of managed apps.
- Allowlist/block: guides which apps can appear or be used.
- Post review: is required to confirm package, version, permissions and managed configuration.
¶ ¶ Operational guidance
- Choose the preset or quick option compatible with the policy objective. Then review the list of apps individually to ensure that no rogue apps were included.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Apps - list
The list of applications configured in the policy.
This area is used to view linked apps, installation status, installation type, permissions, managed settings, and actions per app.
¶ ¶ Featured elements
- Application: shows name and package configured in the policy.
- Installation type: defines whether the app will be mandatory, available, blocked or removed depending on your option.
- Permissions: control access to camera, location, storage and other resources.
- Managed configuration: sends corporate parameters accepted by the app.
- App actions: open editing, removal or detailing of the entry.
¶ ¶ Operational guidance
- Use Add app to add a new app, open the app's actions to edit behavior and confirm that the correct package was selected. For enterprise apps, validate version and managed configuration.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Apps - additional
The additional application settings area.
This area is used to adjust supplemental rules that affect how applications are displayed, installed, updated, allowed, or treated in the policy.
¶ ¶ Featured elements
- Complementary rules: adjust general application behavior.
- Availability: defines whether the app appears to the user or is hidden.
- Updates: control update behavior when supported.
- Extra restrictions: reinforce installation blocking outside the corporate scope.
¶ ¶ Operational guidance
- Review each option before publishing. Use additional settings to enforce allowlist, hide unwanted apps, control permissions, and prevent users from installing apps outside the corporate scope.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Apps tab controls which applications will be available, installed, blocked or configured on devices.
¶ ¶ What can be configured
- Must-have apps.
- Applications available for installation by the user.
- Blocked applications.
- Apps required during provisioning.
- Default permissions.
- Automatic update.
- Managed settings of supported apps.
- Delegated scopes for apps that need to perform administrative actions.
¶ ¶ Common installation types
- Force installed: the app is installed automatically and tends to remain on the device.
- Available: the app is available for the user to install.
- Blocked: prevents use/installation of the app in accordance with the policy.
- Required for setup: app used in the initial provisioning flow.
- Preinstalled: used for apps already present on the system, when applicable.
¶ ¶ When to use managed configurations
Use managed settings to send parameters to your app without user intervention. Examples: server, token, tenant, email, mode of operation, collection behavior, or internal application restrictions.
Attention: Available settings depend on the application. Apps that don't publish managed configurations won't display detailed options.
¶ ¶ Launcher/Kiosk
¶ ¶ Launcher
The main Policy Launcher/Kiosk tab.
This area is used to define what the device's home screen will look like, whether the user will see a controlled launcher, allowed apps or dedicated/kiosk mode.
¶ ¶ Featured elements
- Launcher Tab: controls the home screen and user experience.
- Visible apps: define which shortcuts appear on the device.
- Kiosk mode: restricts use to the set approved by the organization.
- Preview: allows you to validate layout before publishing.
- App fixation: directs the device to a single function when required.
¶ ¶ Operational guidance
- Access Launcher, select the launcher type and define the visible apps. Publish the policy and test it on a pilot device before implementing it en masse.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Choice of launcher
The step of choosing the launcher type.
This area is used to select between home screen templates or kiosk behavior depending on the operation: dedicated device, multiple allowed apps, or single pinned app.
¶ ¶ Featured elements
- Launcher type: defines whether the policy uses Nomid launcher, system launcher or dedicated mode.
- List of options: presents the models available for the scenario.
- Selection: determines the user's initial experience on the device.
- Operational impact: affects access to apps, home screen and device lock level.
¶ ¶ Operational guidance
- Choose the mode appropriate to the case. For restricted operation, prefer a controlled launcher or kiosk. For a device with multiple corporate apps, select the model that allows you to organize the necessary shortcuts.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Launcher preview
The visual preview of the launcher configured.
This area is used to check how applications and shortcuts will appear to the end user before publishing the policy.
¶ ¶ Featured elements
- Preview: shows how the home screen will look to the user.
- Icons and shortcuts: represent released apps and links.
- Visual organization: helps validate usability before publishing.
- Preventive tweak: prevents sending a cluttered screen to many devices.
¶ ¶ Operational guidance
- Review order, icons and apps displayed. If something is missing, go back to the apps/launcher list and adjust. Use preview to avoid publishing an incomplete splash screen.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Launcher definition
The launcher behavior definition area.
This area is used to enable/disable the managed launcher, control the user experience, and choose how the splash screen will be applied.
¶ ¶ Featured elements
- Launcher configuration: defines layout, displayed apps and home screen behavior.
- Item order: controls the arrangement of shortcuts.
- Visual restrictions: limit what the user can access outside of the intended function.
- Publish: applies the experience to devices linked to the policy.
¶ ¶ Operational guidance
- Select the options according to the desired blocking level. Then test on the device to confirm that the Home button, navigation, and opening apps follow the policy.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Pin app
The setting to pin app or set main app in kiosk mode.
This area is used to lock the device to a specific app or highlight mandatory apps in the launcher, reducing usage outside of the function.
¶ ¶ Featured elements
- Pin application: identifies the portal area represented on the screen.
- Fields and indicators: present information that guides the administrator's operational decision.
- Buttons and actions: perform changes, filters, registration or navigation depending on the open module.
- Expected result: keeps the management of mobile assets more traceable, standardized and secure.
¶ ¶ Operational guidance
- Select the app package, define whether it should be fixed/priority and save. Use with caution in single-app operations, as an error may prevent the user from accessing other necessary functions.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
Launcher/Kiosk defines the initial user experience on the device. It is used to limit the device to a set of applications or a specific function.
¶ ¶ Common options
- Nomid Launcher: launcher controlled by Nomid, suitable for dedicated corporate devices.
- System default launcher: maintains the native Android experience, when operation requires more freedom.
- Custom launcher: allows you to define an external app as the home screen, when the company has its own launcher.
¶ ¶ Preview
The preview helps validate the launcher's appearance before applying the policy. It can include wallpaper, screen size, icon distribution and text color.
¶ ¶ Pin app
Pinning an app is useful in single-app kiosk scenarios such as pickup, check-in, sale, point, delivery control, or totem.
Attention: Kiosk devices may block access to Android settings. Ensure there is a maintenance flow for technical support.
¶ ¶ Network
¶ ¶ Network
The main policy network tab.
This area is used to configure connectivity rules, Wi‑Fi, network state, APN, VPN, proxy, and related restrictions.
¶ ¶ Featured elements
- Wi-Fi: shows SSID, connection state or network used when available.
- Mobile data: indicates operator, SIM, roaming or reported cellular connectivity.
- Addresses and network identifiers: support troubleshooting with infrastructure and operators.
- Connection State: helps separate internet failure from policy or application failure.
¶ ¶ Operational guidance
- Access Network, choose the necessary subsection and configure only what should be managed. Incorrect network settings can leave the device unable to communicate with MDM.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Connectivity
The connectivity section of the network policy.
This area is used to define rules related to the use of Wi‑Fi, mobile data, roaming, tethering, Bluetooth, or other available connectivity controls.
¶ ¶ Featured elements
- Wi-Fi networks: allow you to deliver SSID, password and security type per policy.
- Mobile data: maintains field connectivity when there is a chip.
- Radio Settings: control features such as Bluetooth, NFC, hotspot and roaming as supported.
- Operational objective: avoid loss of communication and reduce manual configurations on the device.
¶ ¶ Operational guidance
- Activate or block features depending on the device profile. For field equipment, validate mobile and roaming data; for indoor environments, prioritize managed Wi-Fi and blocking inappropriate sharing.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Network status
The network status/configuration section.
This area is used to control Android behaviors related to network change, network reset, carrier selection and parameters that impact connection.
¶ ¶ Featured elements
- Wi-Fi: controls whether the user can change networks or whether the policy must deliver known networks.
- Mobile data: defines restrictions related to the cellular network when supported.
- Roaming: controls use outside the main network to avoid undue costs.
- Tethering/hotspot: blocks or releases internet sharing.
- Bluetooth/NFC: may be limited depending on the security profile.
¶ ¶ Operational guidance
- Configure the fields according to company policy. If the user should not change network, block changes. If the support needs to allow local adjustment, leave the corresponding option enabled.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Other network settings
The other network settings section.
This area is used to adjust additional options that don't just fit into Wi-Fi, APN, or VPN, such as connectivity preferences and auxiliary blocks.
¶ ¶ Featured elements
- Complementary settings: bring together network options that do not belong to Wi-Fi, APN, VPN or proxy.
- Change permissions: define what the user can modify on Android.
- Sharing control: limits hotspot, tethering or related resources.
- Standardization: reduces configuration variation between devices of the same operation.
¶ ¶ Operational guidance
- Review the options one by one and apply only necessary controls. If in doubt, test on a few devices to avoid mass connectivity loss.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ APN
The APN section of the policy.
This area is used to configure corporate or carrier APN so that devices with physical chip/eSIM use mobile data correctly.
¶ ¶ Featured elements
- APN Policy: controls mobile hotspot settings.
- Override APNs: defines whether the policy replaces existing APNs or just complements them.
- Registered APNs: list operator settings applicable to the chips.
- Preferred APN: indicates which configuration should be prioritized by the device.
- Field validation: requires compatible chip, signal, released mobile data and manufacturer support.
¶ ¶ Operational guidance
- Activate APN configuration, select an existing template or add custom APN. Enter APN, type, MCC/MNC or carrier identifier when necessary, save and test mobile data on the device.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Custom APN
The custom APN form.
This area is used to manually register operator parameters, such as name, APN, user, password, authentication type, protocol, roaming and network identifiers.
¶ ¶ Featured elements
- APN name: identifies the operator configuration displayed to the system.
- APN: informs the access point provided by the operator or MVNO.
- MCC/MNC or operator: relates the rule to the correct mobile network.
- APN types: define traffic as default, supl, mms or others accepted.
- Protocol and roaming: adjust IPv4/IPv6 and behavior outside the main network.
- Username, password and authentication: must be filled in when the operator requires credentials.
¶ ¶ Operational guidance
- Fill in the data provided by the operator exactly as specified. Then publish the policy and validate that the device selects the correct APN and browses mobile data.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ VPN
The VPN section within the network policy.
This area is used to define whether devices will use corporate VPN, always-on VPN, or restrictions related to secure traffic.
¶ ¶ Featured elements
- VPN Profile: defines the corporate connection that can be delivered to the device.
- Application or provider: indicates the app responsible for the VPN when necessary.
- Always-on VPN: keeps traffic tied to the VPN for greater control.
- VPN-Free Blocking: prevents traffic outside the tunnel when configured.
- Server parameters: must follow the organization's network infrastructure.
¶ ¶ Operational guidance
- Select the VPN app/setting, set the desired behavior, and confirm that the VPN app is installed per app policy. Test authentication and traffic before batch deployment.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ VPN configuration
The VPN configuration detail.
This area is used to enter specific VPN parameters, such as app packaging, always-on mode, VPN-free blocking, and connection options.
¶ ¶ Featured elements
- VPN Profile: defines the corporate connection that can be delivered to the device.
- Application or provider: indicates the app responsible for the VPN when necessary.
- Always-on VPN: keeps traffic tied to the VPN for greater control.
- VPN-Free Blocking: prevents traffic outside the tunnel when configured.
- Server parameters: must follow the organization's network infrastructure.
¶ ¶ Operational guidance
- Fill in the fields required by the VPN provider. Save, publish the policy and validate on a pilot device that the VPN connects automatically and does not block essential services.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Proxy
The network proxy section.
This area is used to configure global proxy or proxy parameters to control and audit device network traffic.
¶ ¶ Featured elements
- Proxy host: defines the address of the server that will intermediate navigation.
- Port: indicates the communication channel used by the proxy.
- Exceptions: release domains or addresses that should not go through the proxy.
- Application by policy: standardizes navigation, auditing and traffic control on devices.
¶ ¶ Operational guidance
- Enter host, port and exclusions when applicable. Only use proxy when the infrastructure is prepared, as host/port errors can prevent apps from browsing and communicating.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Network tab controls network connectivity and restrictions.
¶ ¶ Common Settings
- Wi-Fi and connectivity status.
- Restrictions on user network changes.
- APN for corporate mobile data.
- VPN required or configured.
- Proxy for HTTP/HTTPS traffic, when used by the company.
- Additional settings related to roaming, tethering and mobile networks, as supported by Android.
¶ ¶ APN
APN configuration is used when the operator requires specific parameters for mobile data. In general, it is necessary to validate:
- Display name.
- APN.
- MCC/MNC or operator identifier, when applicable.
- APN type, such as
defaultandsupl. - Protocol and roaming.
- Username, password and authentication, when required by the operator.
Attention: APN is sensitive to operator, chip, manufacturer and Android version. Always validate on a real device before applying en masse.
¶ ¶ VPN and Proxy
VPN and Proxy should only be configured when the company's infrastructure requires controlled routing, filtering, inspection, or access to internal resources.
¶ ¶ Configuration
¶ ¶ Configuration
The main general policy settings tab.
This area is used to adjust controls that affect device behavior, user experience, system, managed profile, and remote functions.
¶ ¶ Featured elements
- Settings reported: show status of resources controlled by policy.
- Disagreements: indicate when the device has not yet applied an expected rule.
- Technical details: support analysis of restrictions, permissions and management status.
- Support reference: serves to compare the device with others in the same group.
¶ ¶ Operational guidance
- Enter the Configuration tab and review the subsections. Apply options according to the use case, documenting changes that alter the end user experience.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Device Configuration
The device settings section.
This area is used to control features such as camera, screenshot, volume, Bluetooth, SMS, first-time tips and other Android permissions.
¶ ¶ Featured elements
- Device Settings: control general managed Android behavior.
- User Resources: define what can be changed in local settings.
- Expected State: represents how the equipment should operate after applying the policy.
- Support use: helps compare defined configuration with the actual reported state.
¶ ¶ Operational guidance
- Activate or block each feature according to corporate policy. On dedicated devices, block unneeded resources; on productivity devices, keep what the user needs to use enabled.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Policy configuration
The policy settings section.
This area is used to define global policy behaviors such as default app permission, updates, overlapping windows, keyguard, and general enforcement rules.
¶ ¶ Featured elements
- Policy parameters: define administrative rules for the applied set.
- Scope of application: relates the policy to eligible devices.
- Update options: affect how changes reach the fleet.
- Change control: must be monitored to avoid impact on production.
¶ ¶ Operational guidance
- Configure the default policy before adjusting individual apps. For example, choose whether to grant, deny, or prompt user permissions, and review the impact on enterprise apps.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ System configuration
The system settings section.
This area is used to control Android updates, system behavior, maintenance windows, and operational parameters that affect stability and security.
¶ ¶ Featured elements
- System Settings: controls native Android settings.
- Change permissions: define whether the user can modify sensitive options.
- Standardization: maintains devices with consistent behavior.
- Compatibility: may vary by Android version, manufacturer and management mode.
¶ ¶ Operational guidance
- Define the update strategy according to the risk: immediate for security, scheduled window for critical operation or postponement when internal validation is pending.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Profile configuration
The profile settings section.
This area is used to adjust managed profile elements, separation of personal/corporate data, and behaviors related to Android Enterprise.
¶ ¶ Featured elements
- Management profile: defines behavior related to the corporate profile or dedicated device.
- Data separation: supports work and personal scenarios when applicable.
- Profile restrictions: limit copying, sharing or use outside the corporate context.
- Practical application: helps maintain BYOD or COPE compliance when used.
¶ ¶ Operational guidance
- Use in scenarios with specific work profiles or separation rules. Review the enrollment type before applying, as not all options make sense for a fully managed/dedicated device.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Remote configuration
The remote settings section.
This area is used to enable and parameterize remote support features, collection or auxiliary components used by Nomid for technical operation.
¶ ¶ Featured elements
- Remote application: defines resource used for remote support when available.
- Required permissions: include screen, accessibility, camera, microphone or other resources depending on the app.
- Availability: ensures that support is able to initiate service on the device.
- Security: must follow the organization's authorization and traceability.
¶ ¶ Operational guidance
- Enable only necessary features and confirm that helper apps are installed per policy. In remote support, validate customer permissions, security, and authorization.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Configuration tab brings together general controls for the device and policy behavior.
¶ ¶ Examples of controls
- System updates.
- Automatic application updates.
- Default permissions.
- Fully managed work profile or device settings.
- Remote settings used by Nomid helper apps.
- Synchronization parameters and agent behavior, when available.
¶ ¶ Recommended use
Use this tab to set the fleet's default behavior. More restrictive items must be tested before applying in production, especially when they affect system updates, permissions, management mode or auxiliary apps.
¶ ¶ Hardware
¶ ¶ Hardware
The policy's main hardware tab.
This area is used to control physical resources and behaviors linked to the equipment, such as USB, media, microphone, factory reset, and power modes.
¶ ¶ Featured elements
- Manufacturer/model: identifies the physical family of the equipment.
- IMEI, serial and identifiers: support inventory, warranty, blocking, chip and asset traceability.
- Battery and power: show field operation capability and possible load failures.
- Memory and storage: help identify lack of space or performance limitations.
¶ ¶ Operational guidance
- Access Hardware and configure restrictions compatible with the use of the device. Test before applying en masse, as physical blockages may affect support and maintenance.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Hardware restrictions
The hardware restrictions section.
This area is used to lock or unlock features such as USB debugging, mounting physical media, microphone, safe mode, factory reset, and changing accounts.
¶ ¶ Featured elements
- Camera: can be released or blocked according to security policy.
- USB: controls transfer, debugging, or accessory use when supported.
- Microphone and sensors: can be restricted depending on the device's function.
- Screenshot: can be blocked to protect sensitive data.
- Daily use: reduces risks in field environments, schools, POS or regulated operations.
¶ ¶ Operational guidance
- Disable features that pose a security risk or management leak. Keep USB debugging enabled for maintenance policies only and remove after service.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Battery and power
The battery and power section.
This area is used to define behaviors when the device is connected to power, such as keeping screen/activity active on AC charger, USB or wireless source.
¶ ¶ Featured elements
- Power settings: adjust behaviors that affect autonomy.
- Brightness and screen: can influence consumption and usability.
- Battery saving: must be evaluated so as not to harm collection, location or critical apps.
- Diagnosis: helps understand availability failures in the field.
¶ ¶ Operational guidance
- Configure according to the scenario: totems and panels may need to remain active; Mobile devices should generally save battery power. Test consumption and heating impact.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Hardware tab controls physical resources and behaviors linked to the equipment.
¶ ¶ Examples of restrictions
- Camera.
-Bluetooth. - USB/file transfer.
- Screenshot.
- Microphone, when supported by policy/device.
- Power behavior or screen on during charging.
¶ ¶ Battery and power
Power settings help in totem, fixed device, or embedded operation scenarios where equipment needs to remain active when connected to a power source.
¶ ¶ Security
¶ ¶ Security
The main policy security tab.
This area is used to concentrate controls for authentication, password, FRP, sensitive restrictions, location, Play Integrity, private keys, accessibility, and input methods.
¶ ¶ Featured elements
- Compliance indicators: summarize devices at risk, pending configuration or inadequate security posture.
- Critical events: must be handled before low priority adjustments.
- Relationship with policies: allows you to identify whether password, FRP, restrictions, Play Integrity or blocks are applied correctly.
- Latest report: helps differentiate active problem from old information sent by the device.
¶ ¶ Operational guidance
- Access Security and navigate through the subsections. First define critical rules such as password, FRP, and security posture, then adjust exceptions and allowed services.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Device Login
The device login/lock section.
This area is used to define requirements related to Android unlocking, local authentication, and lock screen behavior.
¶ ¶ Featured elements
- Device login: identifies the portal area represented on the screen.
- Fields and indicators: present information that guides the administrator's operational decision.
- Buttons and actions: perform changes, filters, registration or navigation depending on the open module.
- Expected result: keeps the management of mobile assets more traceable, standardized and secure.
¶ ¶ Operational guidance
- Configure according to the required security level. For shared/dedicated devices, avoid requiring a password if it interferes with operation; for sensitive data, require strong PIN/password.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Password in settings
The password section in the device settings.
This area is used to control whether the user can change password or access options related to the lock credential.
¶ ¶ Featured elements
- Password complexity: defines PIN, password, pattern or minimum requirements.
- Minimum size: increases resistance against unauthorized access.
- Expiration and history: may require exchange and prevent replay when supported.
- Invalid attempts: may trigger blocking or cleaning according to policy.
- Daily application: protects corporate data from loss, theft or improper sharing.
¶ ¶ Operational guidance
- Define whether the end user can manage their own password. On restricted corporate devices, limit changes to avoid loss of access and call support when necessary.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Factory Reset Protection
The Factory Reset Protection (FRP) section.
This area is used to preserve protection against improper reset and define accounts authorized to recover the device after factory reset.
¶ ¶ Featured elements
- Factory Reset Protection: prevents unauthorized use after factory reset.
- Authorized accounts: define who can reactivate the device after reset.
- Property protection: reduces the risk of improper reuse in case of loss or theft.
- Operational attention: must be configured with accounts controlled by the company to avoid legitimate blocking.
¶ ¶ Operational guidance
- Register authorized corporate emails and review before applying. A poorly configured FRP may prevent the device from being reusable after wipe or reset.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Security restrictions
The general security restrictions section.
This area is used to block sensitive features like USB transfer, sharing, calling, roaming, security changes, and other Android controls.
¶ ¶ Featured elements
- Installation from unknown sources: blocks APKs outside the approved stream.
- Sharing and copying: limits data leakage between apps or profiles.
- Sensitive features: controls camera, capture, debug and critical settings.
- Compliance: maintains devices that comply with the organization's internal rules.
¶ ¶ Operational guidance
- Enable only what is necessary for the device's function. In field policies, review calls and roaming; in kiosk policies, block resources that allow escape from the controlled environment.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Block message
The blocking message setting.
This area is used to display a message on the locked screen, with company identification, return instructions or support contact.
¶ ¶ Featured elements
- Block message: identifies the portal area represented on the screen.
- Fields and indicators: present information that guides the administrator's operational decision.
- Buttons and actions: perform changes, filters, registration or navigation depending on the open module.
- Expected result: keeps the management of mobile assets more traceable, standardized and secure.
¶ ¶ Operational guidance
- Write a short and useful message, such as “Corporate device. If lost, contact support@company.com”. Save and validate on the device after synchronization.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ App management
The app management section within security.
This area is used to control installation from unknown sources, automatic updates, changing apps and other behaviors that impact environmental protection.
¶ ¶ Featured elements
- Apps Tab: centralizes applications applied to devices.
- Add app: includes apps from the Library or Managed Google Play.
- Installation behavior: defines whether the app will be mandatory, available, removed or blocked.
- Permissions and managed configurations: adjust the operation of the app without user intervention.
- Validation: confirms that the correct packet will be delivered to the device group.
¶ ¶ Operational guidance
- Set an update policy compatible with the operation and block installation outside of Managed Google Play when the device is corporate/dedicated.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Location
The location-related security section.
This area is used to control whether location can be enabled, disabled, or shared by the device, according to corporate rules.
¶ ¶ Featured elements
- Last Position: shows the most recent location reported by the device.
- Map: allows you to interpret the position in the operational territory.
- Collection date: indicates whether the information is recent or historical.
- History: supports route investigation, loss, theft, improper displacement or field service.
¶ ¶ Operational guidance
- Configure the expected localization mode and align with the collection used by Dashboard/Devices. If the company relies on geolocation, avoid allowing the user to disable the feature.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Advanced
The advanced security section.
This area is used to adjust less frequent controls, typically used for specific device compliance, support, or hardening requirements.
¶ ¶ Featured elements
- Advanced: identifies the portal area represented on the screen.
- Fields and indicators: present information that guides the administrator's operational decision.
- Buttons and actions: perform changes, filters, registration or navigation depending on the open module.
- Expected result: keeps the management of mobile assets more traceable, standardized and secure.
¶ ¶ Operational guidance
- Change advanced options only when there is a clear reason. Test on a pilot device and document your decision, as these fields may affect basic Android functionality.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Security assessment
The device security/posture assessment section.
This area is used to define how MDM handles devices with secure, unknown, at risk, or potentially compromised posture.
¶ ¶ Featured elements
- Play Integrity/posture: assesses device risk and environmental integrity.
- Risk states: may indicate a compromised, unsafe or unassessed device.
- Configured action: defines allow, block, quarantine or delete according to available policy.
- Incident response: prioritizes risky equipment before simple operational problems.
¶ ¶ Operational guidance
- Choose the action for each posture, such as allow, keep under observation, quarantine or remove. Use stricter rules for critical fleets and validate with testing before applying en masse.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Mandatory rules
The mandatory security rules section.
This area is used to configure rules that must be met by the device and actions when the equipment does not meet the requirements.
¶ ¶ Featured elements
- Mandatory rules: define minimum requirements for the device to remain compliant.
- Application condition: determines when a rule must be fulfilled.
- Action on failure: guides blocking, alerting, fixing or other supported response.
- Governance: guarantees minimum safety standards for the entire fleet.
¶ ¶ Operational guidance
- Define the condition, deadline and consequence. Use binding rules to force configuration update, compliance, or correction, preventing insecure devices from remaining in operation.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Password Policy
The password policy section.
This area is used to require complexity, size, expiration, history, and unlock requirements as per the security profile.
¶ ¶ Featured elements
- Password complexity: defines PIN, password, pattern or minimum requirements.
- Minimum size: increases resistance against unauthorized access.
- Expiration and history: may require exchange and prevent replay when supported.
- Invalid attempts: may trigger blocking or cleaning according to policy.
- Daily application: protects corporate data from loss, theft or improper sharing.
¶ ¶ Operational guidance
- Configure the minimum required level and publish. To avoid operational blockages, communicate with users and test requirements on devices with different Android models/versions.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Private key
The private key rule section.
This area is used to control which apps or URLs can use certificates/private keys installed on the device.
¶ ¶ Featured elements
- Certificates and keys: control credentials used by apps, Wi-Fi, VPN or corporate services.
- Managed installation: delivers cryptographic material without manual intervention.
- Access restriction: protects keys against export or misuse.
- Attention: only use valid certificates issued by the correct authority.
¶ ¶ Operational guidance
- Add rule, enter URL pattern, key alias and authorized packages. Use when corporate apps require certificate authentication without releasing it to any application.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Accessibility
The allowed accessibility services section.
This area is used to define which apps can use accessibility APIs, a sensitive feature that can control screen, clicks and content reading.
¶ ¶ Featured elements
- Accessibility services: can be released for support apps, automation or assistive resources.
- Risk of abuse: inappropriate services can control the screen or capture information.
- Allowlist: should limit which apps can use accessibility.
- Remote support: may depend on this permission in some scenarios.
¶ ¶ Operational guidance
- Add only trusted and necessary packages, such as audited enterprise apps. Do not release accessibility generally, as this increases the risk of abuse by inappropriate apps.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Input method
The allowed input methods section.
This area is used to control keyboards and input methods that can be used on the device.
¶ ¶ Featured elements
- Allowed keyboards: define which input methods can be used.
- Blocking external keyboards: reduces the risk of inappropriate data capture or sending.
- Standardization: maintains consistent experience for the end user.
- Compatibility: check the corporate app before restricting input methods.
¶ ¶ Operational guidance
- List authorized keyboard packages or maintain corporate standard. Use to prevent unknown keyboards in environments with sensitive data.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Security tab contains device protection controls, password, FRP, application installation, location, integrity assessment and advanced restrictions.
¶ ¶ Common controls
- Require or configure unlock password.
- Set minimum password complexity.
- Block password changes by the user, when applicable.
- Configure Factory Reset Protection (FRP) to prevent unauthorized reactivation after reset.
- Control installation of unknown apps.
- Prevent removal of managed apps.
- Require Google Play Protect/security checks.
- Set message on locked screen.
- Control accessibility services and input methods.
- Configure certificates/private keys, when used.
¶ ¶ Security assessment
Security assessment helps classify devices according to posture and risk. Use this information to identify equipment that is potentially compromised, lacking adequate checks, or not behaving as expected.
Caution: Password rules, FRP, and advanced locks can prevent local support if configured incorrectly. Document authorized accounts and maintain recovery procedure.
¶ ¶ Geofence
¶ ¶ Geofence
The main policy Geofence tab.
This area is used to configure geographic area-based rules to monitor or restrict usage based on the device's location.
¶ ¶ Featured elements
- Geofence: applies rules based on location.
- Authorized area: defines where the device must operate.
- Input or output: can trigger different behavior depending on configuration.
- Daily use: helps control assets by branch, route, customer, project or school.
- Prerequisite: requires active location collection and device communication.
¶ ¶ Operational guidance
- Access Geofence, create or edit a rule and define area, radius, behavior and notification. Use in operation scenarios by region, branch, construction site, school or route.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Geofence information
The general information section of the geofence.
This area is used to name the rule, define status, description, and basic parameters that identify the geofence.
¶ ¶ Featured elements
- Geofence name: identifies the controlled area.
- Description: documents the purpose of the rule.
- Radius or area: defines the geographical limit applied.
- Associated policy: determines which rules change when the device enters or leaves the area.
- Status: indicates whether the rule is active or in preparation.
¶ ¶ Operational guidance
- Enter a clear name, such as “Center Branch — radius 500m”, and fill in the mandatory fields. Use standardized names to facilitate auditing and support.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Geofence coordinates
The coordinates and map section of the geofence.
This area is used to select the point on the map and configure latitude, longitude and radius of the monitored area.
¶ ¶ Featured elements
- Latitude: defines the north-south axis of the center point.
- Longitude: defines the east-west axis of the center point.
- Radius: determines the operating range in meters.
- Map: helps validate whether the area correctly covers branch, school, customer or operational base.
- Accuracy: depends on GPS, network and device collection frequency.
¶ ¶ Operational guidance
- Use the map to position the area or enter coordinates manually. Adjust radius with realistic allowance for GPS/network variations and test with on-site device.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
Geofence allows you to condition rules to a geographic area. It is useful when devices must operate only in a permitted branch, school, warehouse, route, store, or region.
¶ ¶ Common fields
- Name of the area.
- Description.
- Coordinates or selection on the map.
- Radius/limit of the area.
- Behavior when entering, leaving or remaining outside the area, depending on the available configuration.
¶ ¶ Care
- Enable location collection in the policy.
- Test accuracy in a real environment.
- Consider that indoor GPS may vary.
- Avoid very small areas when the device's accuracy is not sufficient.
¶ ¶ Timefence
¶ ¶ Timefence
The main Timefence/Policy Times tab.
This area is used to define operating windows by day/time, controlling when apps or rules should be active.
¶ ¶ Featured elements
- Timefence: applies rules according to time and day.
- Allowed hours: limits use to the period of work, class or operation.
- Blocked periods: reduce inappropriate use outside of working hours.
- Combination with policies: allows you to change restrictions depending on the time of day.
- Attention: review your time zone and operational calendar before publishing.
¶ ¶ Operational guidance
- Access Timefence, create a rule and define days and times. Use to release apps during office hours and restrict apps outside of work hours.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Timefence configuration
The initial screen for configuring a Timefence rule.
This area is used to create a rule with name, default behavior, and apps or resources affected by the time.
¶ ¶ Featured elements
- Configuration tab: brings together general settings that do not pertain to apps, network or security.
- Configuration groups: organize device, policy, system, profile and remote.
- Desired state: defines how Android should behave after synchronization.
- Validation: must be compared with the device file in Devices.
¶ ¶ Operational guidance
- Select to add rule, enter name and choose default action. Then select the affected apps/packages and proceed to configure days and time slots.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Timefence detail
The Timefence days and times configuration detail.
This area is used to select days of the week, start/end time and applied behavior inside or outside the configured window.
¶ ¶ Featured elements
- Days of the week: define when the hourly rule is valid.
- Start and end times: establish the permitted or restricted usage window.
- Time zone: ensures correct interpretation for devices in different regions.
- Action applied: defines policy, restriction or behavior during the window.
- Exceptions: must be handled with specific policies when there is non-standard operation.
¶ ¶ Operational guidance
- Mark the days, enter times in the organization's zone and save. Especially validate policies used in shifts, as incorrect time zones can block apps at the wrong time.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
Timefence allows you to apply rules by day and time. It is recommended to limit use outside of working hours, release applications only during shifts or differentiate behavior between working hours and maintenance.
¶ ¶ What to configure
- Days of the week.
- Start and end time.
- Time zone considered.
- Rule applied inside or outside the window.
- Exceptions or default behavior when available.
Tip: In operations with night shifts, validate windows that cross midnight.
¶ ¶ Contacts
¶ ¶ Contacts
The main policy contacts tab.
This area is used to link corporate contact lists to devices to facilitate calls and controlled communication.
¶ ¶ Featured elements
- Contact list: defines corporate contacts available to devices.
- Name and number: identify authorized people, sectors or services.
- Distribution by policy: delivers contacts only to relevant devices.
- Operational use: facilitates calls to support, supervision, emergency or internal staff.
¶ ¶ Operational guidance
- Access Contacts and select the list created in the Library. Publish the policy and confirm on the device that the contacts appear as expected.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Contact list
The list or selection of contacts available for the policy.
This area is used to choose which contacts or lists will be distributed to managed devices.
¶ ¶ Featured elements
- Contact list: defines corporate contacts available to devices.
- Name and number: identify authorized people, sectors or services.
- Distribution by policy: delivers contacts only to relevant devices.
- Operational use: facilitates calls to support, supervision, emergency or internal staff.
¶ ¶ Operational guidance
- Select the desired list, save the policy and apply. Keep the list updated in the Library so that changes can be reused across multiple policies.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Contacts tab associates lists of authorized contacts with the policy. This is useful on restricted devices where the user should only access specific corporate contacts.
¶ ¶ Common use
- Allow contact with support.
- Allow contact with supervisors.
- Distribute list of extensions or telephone numbers per branch.
- Use contacts previously registered in Library > Contacts.
¶ ¶ Data collected
¶ ¶ Data collected
The main tab for data collected by the policy.
This area is used to define what information Nomid MDM should request and store about apps, device, usage and location.
¶ ¶ Featured elements
- Collected Data: defines which reports the portal will receive from devices.
- Level of detail: controls whether collection occurs by app, device, usage or location.
- Data impact: more collection generates more visibility, but also more traffic and privacy liability.
- Governance: only enable information necessary for operation and support.
¶ ¶ Operational guidance
- Access Collected Data and enable only the data necessary for operation, support, compliance and reporting. Inform users/customers when there is sensitive collection, such as location.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Data per application
The application-level collected data section.
This area is used to enable collection of information such as installed/removed apps, versions, installation status, and app-related reports.
¶ ¶ Featured elements
- Data by app: controls reports related to applications.
- Installation and removal: records changes to the app base.
- Version and package: support auditing and compatibility.
- Usage by app: allows you to understand productivity and consumption by application.
¶ ¶ Operational guidance
- Enable it when you need to audit apps, validate installation or track versions. Disabling may reduce visibility into rogue apps or installation failures.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Device data
The data collected section of the device.
This area is used to collect information about hardware, system, network, memory, battery and technical properties of the equipment.
¶ ¶ Featured elements
- Technical inventory: includes model, system, hardware and identifiers when enabled.
- Device status: includes battery, memory, network and reported settings.
- Purpose: support support, auditing and asset management.
- Privacy: only collect data necessary for the contracted operation.
¶ ¶ Operational guidance
- Activate the items required for support and inventory. This data helps diagnose model, Android, storage, network, and compliance.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Usage data
The usage data section.
This area is used to collect metrics such as screen time, usage per application, data consumption and other operational indicators.
¶ ¶ Featured elements
- Screen time: records intensity of device use.
- Data consumption: measures impact on network and franchise.
- Power and connectivity events: help explain unavailability.
- Operational analysis: identifies idleness, excessive use or behavior outside of expectations.
¶ ¶ Operational guidance
- Enable it when the company needs to analyze productivity, consumption or misuse. Then consult the data on the Dashboard or in the Usage tab of the device file.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ Geolocation data
The geolocation data section.
This area is used to configure location collection, range, minimum offset, and rules related to position update.
¶ ¶ Featured elements
- Position collection: records location according to policy and permissions.
- Collection interval: defines update frequency.
- Minimum displacement: prevents excessive recording when the device does not move.
- Responsible use: must respect corporate purpose, transparency and applicable legal basis.
¶ ¶ Operational guidance
- Define interval and distance according to operational needs. Smaller intervals give more precision, but increase battery/data consumption. Test before applying to the entire fleet.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
The Collected Data tab defines what information will be collected and displayed on the portal.
¶ ¶ Data types
- App level: data per application, such as version, status, usage and consumption, when available.
- Device: technical information about the device, system, hardware, network and security.
- Usage: usage data, screen time and activity.
- Geolocation: current location or location history, when enabled.
¶ ¶ Impact of disabling collection
If a collection is disabled, the related Dashboard and Devices screens may be empty or incomplete. Disable only when there is an operational, contractual or privacy reason.
¶ ¶ History
¶ ¶ History
The main policy history tab.
This area is used to query policy-related changes, versions, and events over time.
¶ ¶ Featured elements
- Timeline: lists relevant policy changes and events.
- Author of change: helps track who modified the configuration.
- Date and time: allow you to correlate changes with incidents on devices.
- Event detail: shows what was changed, published or executed.
- Audit: serves as evidence for support and governance.
¶ ¶ Operational guidance
- Access History to review who changed it, when they changed it and which version was generated. Use before investigating behavior change on devices.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
¶ ¶ History detail
The policy history records detail.
This area is used to view specific events, versions, and audit information with more granularity.
¶ ¶ Featured elements
- Timeline: lists relevant policy changes and events.
- Author of change: helps track who modified the configuration.
- Date and time: allow you to correlate changes with incidents on devices.
- Event detail: shows what was changed, published or executed.
- Audit: serves as evidence for support and governance.
¶ ¶ Operational guidance
- Click on the record or review the chronological list. Use history to track changes, restore understanding of old configurations, and justify changes in audits.
- Before saving, publishing, or running commands, confirm that the selected company, group, policy, or device matches the desired scope.
History shows changes and events related to the policy.
¶ ¶ What is it for
- Audit who changed a policy.
- See when a setting has been modified.
- Investigate regressions after recent change.
- Check version evolution.
¶ ¶ Checklist before publishing a policy
- Does the name of the policy make the group and purpose clear?
- Was the policy tested on a few devices before mass application?
- Have required, blocked and available apps been reviewed?
- Does the launcher/kiosk have a maintenance path?
- Have APN, VPN and proxy been validated on a real device?
- Have password rules, FRP and advanced locks been documented?
- Are collections required for Dashboard, location and usage enabled?
- Are the associated devices in the correct group?
- Does the support team know how to revert or switch to a maintenance policy?