Get fresh insights, pro tips, and thought starters–only the best of posts for you.
Dynamic parameters turn static MDM policies into reusable templates that adapt to each device or user at deployment. By resolving device, identity, and administrative attributes in policies, profiles, and scripts, IT teams can personalize configurations, reduce duplication, and simplify onboarding, network access, and app setup. Effective use depends on accurate source data, tested payloads, fallback logic, and keeping secrets out of dynamic configurations.
Whether it’s organizing resources across an enterprise or managing a growing fleet of devices, labeling remains the foundation of order. At its simplest, a label supports device identification, organization, and policy targeting. In many MDM deployments, attributes such as device name, asset tag, department, and ownership type are used as static markers to group devices and target policies in bulk.
This approach worked well when device environments were predictable. But as organizations scale and use cases diversify, rigid one-to-many configurations begin to fall short. Device management is no longer just about tracking endpoints; it’s about responding to context. This shift marks the move from static management to automation that adapts in real time.
Traditional device management relies on broad classifications: a single policy applied to many devices based on fixed attributes. Dynamic parameters change this model. They can function as variables that resolve stored device or user attributes when a policy or script is processed.
This enables a one-to-each approach. While policies can still be deployed at scale, supported fields can be populated with device- or user-specific values such as usernames, email addresses, serial numbers, departments, and enrollment information. The result is personalization without added administrative complexity.
The transition from rigid profiles to context-aware automation represents the next phase of MDM evolution. Modern Unified Endpoint Management solutions like Hexnode extend the role of device attributes beyond identification. Leveraging dynamic wildcards enables runtime parameter resolution across configuration payloads, while dynamic groups enforce conditional policy targeting based on real-time system telemetry.
Understanding how dynamic parameters function under the hood is what separates basic “fill-in-the-blank” automation from truly context-aware device management. At its core, the architecture follows a simple but powerful cycle built on two key stages: attribute mapping and variable resolution.
Instead of treating policies as static text, dynamic parameters allow them to behave like templates that adapt at runtime – using real device and user data.
When a policy containing a wildcard (for example, %email%) is deployed, the system doesn’t push it as-is.
When a policy or action containing a supported wildcard is sent, Hexnode UEM automatically replaces the wildcard with the corresponding device or user information available in the portal, including information provided during enrollment.
When the required information is available and the wildcard is supported in the target field, the policy or action can use device- or user-specific values without requiring separate configurations for each recipient.
Dynamic parameters in Hexnode are organized based on their source of truth. Choosing the right source ensures policies stay accurate as users, devices, and organizational structures evolve.
These attributes are collected during device enrollment and reflect hardware-level information. They’re commonly used for inventory tracking and security enforcement.
Examples:
%serialnumber%, %imei%, %wifimacaddress%, %osversion%
Pro tip: Use %assettag% to bridge physical inventory records with your UEM console.
These wildcards use corresponding user information associated with the enrolled device in Hexnode, such as the user’s name, email address, username, department, domain, or UPN.
Examples:
%name%, %email%, %department%, %userprincipalname%
Impact: A supported Wi-Fi or VPN policy can populate certain username, identity, or account fields with user-specific values, reducing the need to duplicate otherwise identical profiles..
%devicenotes% resolves device notes provided by an administrator, while %newline% inserts a line break and %null% returns no value.
They’re especially useful for scripting, messaging, and advanced policy logic.
| Category | Wildcard | Function / Value Resolved |
| Identity | %name% |
Resolves the device user’s name as displayed in the portal |
%username% |
Resolves the user’s name or associated email address | |
| Network | %ssid%, %wifimacaddress% |
Wi-Fi network name or physical network identifier |
| Hardware | %model%, %serialnumber% |
Manufacturer-provided device identifiers |
| Directory | %domain%, %netbiosname% |
Active Directory or Entra ID domain details |
| Formatting | %newline% |
Inserts a line break (useful for lock screen messages) |
While dynamic device groups determine which devices receive a policy, dynamic parameters operate at a separate stage of policy delivery.They can target endpoints based on conditions such as platform, ownership, department, location, or compliance state.
Dynamic parameters determine which value each recipient receives within that policy. For example, a Wi-Fi policy can be assigned to a defined device group while resolving a different username or email address for every enrolled user.
This distinction helps prevent policy sprawl.
Use groups when a configuration should apply only to a specific set of devices. Use parameters when the configuration is shared but the user- or device-specific values need to change.
A practical example is a remote-access policy. IT can assign it only to employees approved for VPN access, then use dynamic parameters to populate the relevant identity values in the configuration.
Separating policy targeting from policy personalization makes assignments easier to review, troubleshoot, and maintain as the environment changes.
When a supported policy or action is sent, Hexnode substitutes its wildcards using the corresponding device or user information available at that time.
Just up-to-date configurations, applied at the right moment.
Dynamic configuration can reduce policy duplication as fleets grow, although larger environments still require additional support, monitoring, and governance. This is where dynamic parameters move from theory to practice – allowing IT teams to solve real deployment challenges without multiplying policies or scripts.
Below are a few common scenarios that show how Hexnode uses dynamic parameters to simplify complex workflows.
The challenge:
Deploying devices to a global workforce where users require localized settings – time zones, regional formats, and personalized lock screens, without maintaining separate policies for each office or region.
The solution:
Use supported device and user wildcards to personalize fields such as an iOS/iPadOS lock screen message within a broadly assigned policy.
The policy:
Set the lock screen message as:
Property of %domain%. If found, please contact %email% or return to the %department% department.
The impact:
Dynamic endpoint identity resolution automatically attributes assigned ownership upon initial boot—regardless of user location or role—eliminating manual configuration overhead and policy duplication.
The challenge:
Manually configuring VPN or Wi-Fi (802.1X) credentials for hundreds of users. Hard-coded credentials introduce security risks, while manual user input leads to misconfigurations and support overhead.
The solution:
Map identity attributes directly into authentication payloads.
The technical detail:
Use only the wildcard documented for the intended field and platform—for example, %username% in supported Wi-Fi fields and %name% or %email% in supported VPN account fields..
Advanced logic – fallback handling:
In fields that support multiple wildcards, Hexnode allows two wildcards to be separated by OR;
for example
%email%OR%alternateemail%
can populate the first available value in a supported CalDAV username field.
Non-secret inputs—such as usernames, email addresses, asset tags, device IDs, department names, and service URLs—work best as dynamic parameters. However, sensitive secrets like long-lived passwords, API keys, private keys, or shared access tokens should never be distributed via dynamic wildcards. Injecting dynamic variables into scripts or configuration payloads creates exposure risks through system logs, configuration exports, script execution outputs, or local endpoint inspection. Using a dynamic parameter does not change the sensitivity of the resolved value.
For Wi-Fi and VPN access, use certificate-based authentication where the platform and infrastructure support it. For enterprise applications, prefer federated authentication, short-lived tokens, or a secure provisioning workflow over embedded credentials.
Dynamic parameters can still play an important role in these flows. They can identify the user, device, or organizational unit that the authentication process should evaluate.
This keeps shared policies personalized without turning them into a repository for reusable secrets.
The challenge:
Many enterprise applications, such as collaboration tools or internal CRM platforms, require pre-configured values like API keys, workspace URLs, or user identifiers. On iOS and macOS, this often involves complex XML or plist configurations.
The solution:
Inject dynamic parameters directly into XML payloads or scripts.
Instead of creating separate configurations per user, you define a single template using variables.
Example (AppConfig XML):
UserEmail
%email%
DeviceID
%deviceid%
Department
%department%
The result:
Upon deploying supported app-configuration profiles, Hexnode automatically resolves dynamic wildcards using target user and device attributes prior to payload delivery, eliminating manual configuration overhead.
| Feature | Static Approach (Manual) | Dynamic Approach (Automated) |
| Email setup | Separate policies per user or group | Single policy for the entire organization |
| Asset tracking | Manual updates in device notes | Existing asset-tag and serial-number values can be inserted into fields that support %assettag% and %serialnumber%. |
| Scripting | Hard-coded values with high failure risk | Context-aware scripts that adapt per device |
| Missing-value handling | Policy fails when data is missing | In fields that support multiple wildcards, the OR operator can select the first available wildcard value. |
Pass the wildcard using its documented syntax, such as %username%, and quote or escape the resolved value according to the target shell and the script argument format supported by Hexnode. This prevents execution failures when attribute values contain spaces or special characters.
The real strength of dynamic parameters lies in how deeply they integrate into device configuration. Dynamic wildcards extend beyond administrative console fields, enabling direct injection into deployment payloads and management scripts to programmatically govern operating system and application behavior.
This is where Hexnode moves from abstraction to execution.
While Hexnode supports a wide range of dynamic parameters, a small set forms the foundation of most automated workflows.
%deviceid% A unique identifier assigned by Hexnode. Commonly used when integrating with external asset databases, CMDBs, or internal APIs.%email% %department% A key contextual attribute. Ideal for dynamically mapping network drives, assigning permissions, or installing department-specific software via scripts.%assettag% The link between physical and digital inventory. Scanning physical asset tags during procurement and deployment establishes immediate parity between hardware chassis metadata and Unified Endpoint Management (UEM) inventory records.These parameters act as reusable building blocks, enabling consistency without sacrificing flexibility.
Hexnode supports wildcards in custom configurations for iOS/iPadOS and macOS and in supported custom-script workflows; administrators should verify the available wildcards and required syntax for each platform and field. This allows a single deployment artifact to behave differently on every endpoint.
Executing management scripts via Hexnode enables dynamic variable injection, programmatically populating target parameters at runtime.
Example:
Personalized welcome message (PowerShell – Windows)
|
1 2 3 4 5 |
# Using %name% to personalize a toast notification $userName = "%name%" display-notification -Text "Welcome to the team, $userName! Your device is now secured." |
Example:
Standardized computer naming (Bash – macOS)
|
1 2 3 |
# Using %serialnumber% to generate a consistent naming convention sudo scutil --set ComputerName "HEX-%serialnumber%" |
Always wrap dynamic parameters in double quotes (for example, “%name%“). This prevents script failures when values contain spaces or special characters.
Advanced app configurations and system restrictions on Apple platforms often rely on XML or plist payloads. Hexnode allows dynamic parameters to be embedded directly into these files.
Example:
Managed app configuration (XML)
UserEmail
%email%
UserDomain
%domain%
OrganizationUnit
%department%
Before the payload is installed, the dynamic parameters are resolved and replaced with actual user or device values. The device receives a fully populated configuration; no post-install scripting required.
Not every directory is perfectly populated. To prevent policies from failing when an attribute is missing, Hexnode supports logical fallback handling using the OR operator.
Syntax:
%attribute1%OR%attribute2%
Example use case: Use the OR operator only with a supported pair of wildcards in a field that permits multiple wildcards, such as %email%OR%alternateemail%.
This ensures policies remain functional and avoids blank fields or execution errors.
In a dynamic setup, policies are only as reliable as the data they depend on. Even well-designed automation can break if attributes are missing, outdated, or slow to propagate. Most issues don’t appear on Day 1; they surface later, when environments change.
Let’s focuses on those real-world scenarios and how to handle them effectively in Hexnode.
A resolution failure occurs when a policy references a dynamic parameter such as %email% – but the corresponding field is empty in the Hexnode portal or the synced directory service.
Why this matters:
Depending on the platform and payload type, a null value can result in:
How to prevent it:
%department%OR"Corporate"A common point of confusion is why policy behavior doesn’t change immediately after an attribute update.
What’s happening behind the scenes:
When an attribute is updated in a directory service (for example, Microsoft Entra ID), the change must:
The reality:
Depending on sync intervals, this process may take time.
Dynamic environments often involve overlapping groups and policies. When this happens, conflict resolution becomes critical.
Hexnode applies different conflict rules by payload type: restrictions generally use the most restrictive value, passcodes use the highest-complexity requirement, distinct configurations such as Wi-Fi networks may be additive, and certain mutually exclusive settings such as wallpapers use the most recently applied configuration.wins
Where issues arise:
If multiple policies deploy scripts or configurations using the same dynamic parameter, they may overwrite each other on every sync, leading to unstable or “flapping” behavior.
The fix:
Define a clear policy hierarchy.
Organize policies by scope and review how Hexnode resolves overlapping settings. Wildcards themselves resolve from the corresponding device or user information.
Be cautious with special characters. If a user’s %name% is O’Malley, the apostrophe can break a Bash or PowerShell string if not properly escaped. Always test your scripts with “worst-case” data before global deployment.
Adopting dynamic parameters isn’t just a usability upgrade – it’s a structural improvement to how device management scales. As fleets grow, the true cost of IT operations isn’t infrastructure; it’s manual effort. Dynamic policies reduce that effort by design, shifting teams away from repetitive configuration work and toward sustainable governance.
Dynamic configurations deliver immediate ROI by significantly reducing the administrative overhead of policy creation, tracking, and maintenance.
In a non-dynamic setup, organizations often duplicate policies for every department and platform. An environment with 10 departments and 3 operating systems can quickly grow to 30 or more near-identical email or Wi-Fi profiles – each requiring manual updates whenever credentials, certificates, or endpoints change.
Dynamic parameters can allow some shared configuration policies to serve multiple users, groups, or devices without duplicating every policy. By resolving values like %department% and %email% at runtime, those dozens of policies collapse into one without losing specificity.
Measuring the policy-to-device ratio quantifies policy consolidation progress alongside key IT governance metrics, including deployment coverage, exception rates, baseline compliance, and operational requirements. Dynamic parameters can reduce policy duplication by allowing shared configurations to use device- or user-specific values.
In regulated industries such as healthcare and finance, configuration transparency isn’t optional, it’s a requirement.
Removes ambiguity during internal reviews or external audits.
Where supported by the operating system and management payload, policies can reapply or enforce configuration settings during later management check-ins.
While device reports capture centralized inventory and asset-tag telemetry, IT teams must perform routine physical audits to validate physical-to-digital inventory alignment.
This level of traceability turns policy management into a measurable, defensible process rather than a best-effort exercise.
See how Hexnode centralizes endpoint management, policy enforcement, automation, and reporting.
Featured resource
Hexnode Unified Endpoint Management
| Benefit | Impact on IT Teams | Business Outcome |
| Reduced manual entry | Can reduce manual onboarding steps and associated administrative time. | Faster time-to-productivity for new hires |
| Error mitigation | Can reduce manual-entry errors in credentials, paths, and configuration values. | Lower help desk ticket volume |
| Scalability | Adding users requires no new policies | Can reduce the marginal configuration effort associated with adding users or devices. |
| Governance | Centralized control over variable resolution | Consistent compliance with security standards |
A dynamic-first approach future-proofs device management. Instead of manually configuring individual endpoints, IT teams move into an architectural role – designing systems that adapt automatically as users, devices, and requirements change.
Getting started checklist:
Once these foundations are in place, dynamic policies become less of a feature and more of a default operating model, one that scales with the organization rather than against it.
Before rolling dynamic parameters into production, use the following checklist to ensure a smooth and predictable transition:
%assettag% and %department% are resolving correctly across platforms.Dynamic parameters are not an add-on – they’re a mindset shift. Once in place, they allow IT teams to focus less on maintenance and more on designing systems that scale predictably, securely, and with minimal manual intervention.
Moving from static to dynamic device management is not just a matter of convenience, it’s a structural shift in how IT environments scale. By replacing hard-coded configurations with attribute-driven automation, organizations remove the manual friction that typically grows alongside their device fleets.
In a dynamic-first model, policies function as living templates. They adapt automatically to changes in directory data, user context, and device state. A dynamic-first model can reduce per-device configuration effort as fleets grow, but operational requirements still increase with fleet size.
Hexnode wildcards dynamically resolve device- and user-level attributes, automatically populating target policy parameters and remote actions upon deployment.
Use a dynamic parameter when the configuration is the same but values such as a username, email address, or asset tag differ by recipient. Create a separate policy when the devices need materially different settings, restrictions, or deployment conditions.
Use device inventory data for values such as serial numbers, OS versions, and asset tags. Use the corresponding user information available in Hexnode for identity-related wildcards such as %email%, %department%, and %userprincipalname%, and confirm that the intended wildcard is supported in the target field.. The source should be accurate, consistently populated, and reviewed regularly.
Make an attribute mandatory when its absence would make a configuration incomplete or unsafe, such as a required user identity field. Use a fallback for optional values where a safe default keeps the policy functional.
Dynamic parameters should be limited to non-secret values. Do not use them to embed long-lived passwords, API keys, private keys, or shared tokens in scripts or configuration payloads; use certificate-based authentication, federated access, or secure provisioning flows where appropriate.
Verify parameter compatibility with the target profile, script, or payload, ensuring resolved values yield syntactically valid configurations.Test with representative devices and edge-case values, including empty fields, spaces, apostrophes, and special characters.
Define a clear policy hierarchy and avoid assigning multiple policies that manage the same setting without a defined order. This is particularly important when policies manage the same setting. Hexnode evaluates policy conflicts based on payload type, executing one of three distinct resolution models: merging additive configurations, enforcing the most restrictive parameters, or prioritizing the most recently applied policy for mutually exclusive settings.
See how Hexnode helps standardize endpoint policies and reduce manual configuration work.
Start Your 14-day Free Trial Today!
