5 Real-World Wildcard Policy Examples in Hexnode

Why IT admins stop hand-typing usernames into policies

Hexnode wildcard policy examples address a common scaling challenge: repeatedly entering device and user values across supported configurations. One Exchange policy may require a unique username for each user. Likewise, a kiosk web app may need a device-specific URL.

Device reassignment creates another maintenance cycle. An administrator may need to update policies whenever the assigned user or device identifier changes. Typos can also misconfigure accounts, while inconsistent identifiers can undermine asset inventory accuracy.

Instead, Hexnode wildcards can substitute corresponding user or device information when Hexnode sends supported policies or actions. It also supports wildcards across network and account configurations, web apps, app configurations, enrollment workflows, Lost Mode, and custom scripts.

What are wildcards in Hexnode?

Wildcards in Hexnode UEM are placeholders that Hexnode replaces with device-specific or user-specific values when it applies supported policies or actions. These Hexnode wildcard policy examples show how the same mechanism works across different administrative workflows.

Therefore, admins can reuse one configuration while Hexnode resolves each wildcard using the corresponding device or user information available in the portal. The full list of wildcards supported by Hexnode includes identifiers, hardware details, organizational attributes, and user information.

1. One Exchange ActiveSync and Wi-Fi policy for every user

To configure corporate email with one policy, use supported Exchange ActiveSync wildcards in the relevant platform-specific fields. For example, %email% can populate Email Address, while %username% can populate supported User or User Name fields.

Scenario: Your IT team needs to onboard 300 employees across iOS, Android, Windows, and macOS. Instead of maintaining user-specific values, admins can configure supported wildcards once. Available fields and wildcards vary by platform.

Configure the policy

1. Create or edit a policy in the Hexnode UEM portal.
2. Open the platform’s Exchange ActiveSync configuration.
3. Add the appropriate wildcards to the supported fields.
4. Associate the policy with the required devices, device groups, users, or user groups.

For example, %domain% or %netbiosname% can populate Domain, while %email% can populate Email Address. The %username% wildcard works within supported User or User Name fields.

Windows also provides a separate Account Name field with its own supported wildcards.

Admins can apply the same approach to other configurations:

• Wi-Fi: %username% works in supported Username or Identity fields across iOS/iPadOS, Android, macOS, and visionOS.
• VPN: The iOS/iPadOS Account field supports %name% and %alternateemail%, while the macOS Username field supports %email% and %alternateemail%.
• macOS AD Asset Binding: %domain% works for Active Directory Domain. The Username field supports %email%, %name%, and %username%.

2. Passing device identity into a kiosk web app URL

On supported Android and iOS web app kiosks using Hexnode Browser Lite, admins can append wildcards to web app URLs. This lets the URL carry identifiers associated with the requesting device.

Scenario: Retail check-in tablets or warehouse scanners connect to a central web application. The backend needs to identify which store, station, or scanner initiated each request.

These Hexnode wildcard policy examples also extend to kiosk workflows, where wildcards can supply device-specific identifiers through the URL.

Configure the web app

1. Navigate to Apps > +Add Apps > Web App.
2. Add the web app name, icon, and other required details.
3. Enter the URL using the URL/%wildcard% format.
4. Add the web app to the appropriate kiosk policy.
5. Configure Hexnode Browser Lite using the platform-specific Android or iOS web app kiosk workflow.
6. Associate the policy with the required kiosk devices.

Supported web app URL wildcards vary by platform. For Android Hexnode Browser Lite, documented values include %deviceid%, %devicename%, %imei%, %wifimacaddress%, %email%, and %serial%; use the platform-specific wildcard reference when constructing the URL.

3. Pre-filling managed app configurations on Android and iOS

Managed app configuration lets IT admins remotely provide predefined settings that supported business apps consume on managed devices. Android Enterprise provides managed configurations for this purpose. Apple also supports configuration data for managed app deployments.

In Hexnode, admins can use wildcards such as %email%, %username%, and %serialnumber% within supported managed app configurations. Hexnode supports these wildcards in Android App Configurations and within iOS App Configuration XML files.

Configure an Android app

Policies → Android → App Management → App Configurations → Select app → Add wildcards

Then:

1. Select an Enterprise App or Managed Google Play app.
2. Enter supported wildcards into the available configuration fields.
3. Select Done, then save the policy.

Hexnode also supports %phonenumber_sim1% and %phonenumber_sim2% in Android App Configurations. The same dual-SIM wildcards work within iOS App Configuration XML.

Example use case: A line-of-business app accepts a username and device identifier through managed configuration. An admin can supply %username% and %serialnumber% instead of maintaining separate configuration files for each endpoint.

Hexnode then resolves each wildcard to the corresponding user or device value.

4. Personalized Lost Mode, lock screen, and broadcast messages

Hexnode wildcards can personalize Lost Mode messages, iOS/iPadOS lock screen messages, and Broadcast Messages with device or user information.

This can help when IT teams activate Lost Mode across multiple devices after a site incident. Likewise, admins can display device-specific asset information on iOS/iPadOS lock screens for identification and audits.

Here, %newline% inserts a line break on supported Lost Mode configurations.

Supported placement points

Admins can also append wildcards in supported fields. For example, %osname%%osversion% displays the operating system name followed by its version.

5. Wildcards as arguments in custom scripts and user account creation

Hexnode’s Execute Custom Script action accepts wildcards as arguments on macOS and Windows. Therefore, one script can receive endpoint-specific values such as %username%, %email%, %department%, and %serialnumber%.

This supports two distinct administration workflows: creating local macOS accounts and supplying endpoint-specific values to custom scripts.

Create a macOS user account with wildcards

Scenario: Create local macOS accounts using information associated with the enrolled user instead of entering every value manually.

1. Navigate to Manage > Devices and select the target Mac.
2. Select Actions > Policies & Accounts > Create User Account.
3. Enter %name% under Full Name. Hexnode generates the Account Name automatically from the Full Name.
4. Configure the remaining account settings and select Create.

Password, Password Hint, and Aliases also support wildcards.

Pass wildcards as script arguments

A Windows script could, for example, pass %serialnumber% and %department% to an external CMDB.

Script arguments support dynamic substitution, although some wildcards remain platform-specific.

How Hexnode makes wildcards more flexible at scale

The Hexnode wildcard policy examples above cover direct substitution across several administrative workflows. Beyond basic substitution, Hexnode UEM supports fallback logic, enrollment attribute mapping, and wildcard-driven device naming. These capabilities help admins reduce hard-coded values while adapting configurations to different users and devices.

• Logical OR operator: %email%OR%alternateemail% uses %alternateemail% when %email% has no value. Hexnode permits one OR operator per combination. An OR pair must also remain space-separated from other appended wildcards.
• Custom attributes mapping: Enrollment profiles for iOS, macOS, Android, and Windows support wildcard values for custom attribute mapping. Admins can use them to populate organization-specific metadata during enrollment.
• Personalized Device Name: Android Enterprise enrollment profiles support wildcards in the Device Name field. Admins can therefore create personalized device names during enrollment.
• Windows Kiosk Account name: Admins can use %email% or %userPrincipalName% to specify a Microsoft Entra ID kiosk account name.

Together, these Hexnode wildcard policy examples show how admins can use wildcard-driven configurations instead of maintaining separate variants with hard-coded values. When Hexnode sends a supported policy or action, it resolves the wildcards using the corresponding device or user data available for that operation.

Featured resource

Understand Where UEM Fits in Endpoint Management

Explore the foundations of Unified Endpoint Management, common challenges, and how UEM centralizes endpoint administration.

Download the whitepaper

FAQs

Use wildcards to reduce repetitive policy configuration

Hexnode wildcards let admins use device- and user-specific values in supported policy, action, and configuration fields instead of hard-coding those values for individual endpoints.

The five Hexnode wildcard policy examples show how this approach extends beyond basic account configuration. Admins can use wildcards across Exchange ActiveSync, kiosk URLs, managed app configurations, device messages, and custom scripts.

More advanced options, including fallback logic and enrollment-based personalization, provide additional flexibility as deployments grow. The key is to match each wildcard to its supported field and platform before deployment.

Used this way, wildcards reduce repetitive configuration while keeping policies adaptable across changing users, devices, and deployment scenarios.