Smart and automated deployments
Flex Policies let you define rules for filtering devices so that Addigy can automate assigning devices as they check in. It can greatly reduce tedious and repetitive tasks involved in asset deployment, which means that your workload doesn't increase even as your organization grows and changes.
Backwards Compatible
Devices can be assigned to multiple policies, which is a fundamental change to how admins have always used Addigy. However, you do not need to change anything in your policy structure, and you can continue to use a single policy per device as long as you wish. Assigning multiple policies, and automated assignments, are both optional.
Unlocking New Workflows
Using multiple policies opens a lot of possibilities for managing your fleet of devices more efficiently. For example, you can have one policy for System Updates, another for common software, and a third for office printing and network settings.
Different devices can be assigned to one, two, or all three of those policies to suit your needs. When a device checks in, Addigy determines which policies to assign and a combined set of assets is delivered to the device.
Considerations Regarding Multiple Policies
Conflicting Settings
There are a few payloads and settings of a Policy that can cause problems if they are sent to the wrong device. Addigy Identity and Ticketing System Integrations are two examples. We recommend that you be very careful when adding an auto-assignment to a policies with those settings. A better solution is to include Identity, Enrollment Profile, and other similar settings on policies to use only for enrollment (via ADE) and use auto-assignments for common software and other assets.
Read other use cases for Flex Policies
Policy Hierarchy Still Applies
Flex Policies can be structured without the need to nest them under other policies. However, the policy hierarchy — where child policies inherit assets and settings from their parent(s) — is still in effect.
Adding an Auto-Assignment to a Policy
Let's look at the steps required:
- Finding the Auto-Assignment Settings
- Create a filter set to target the devices for the policy
- Checking if a fact exists
- Scoping to other policies
- Testing Auto Assignment Filters
- Disabling an Auto-Assignment
- Location (Policy ID)
- Deploy assets automatically
Finding the Auto-Assignment Settings
In the Overview tab for any Policy, you’ll find the current auto-assignment status. The policy may or may not have an auto-assignment previously saved, or the setting could be deactivated.
Create a filter set to target the devices for the policy
Create each filter using any standard, custom device fact, or static field available. Example: ‘Device Model Name’ equals ‘MacBook Pro’
Creating a simple rule takes just a few clicks, but you can create complex combinations of rules using logical "and" and "or" operators.
Note: All additional filters within the same block are to be treated as AND logical operators. Meaning the device must meet Filter #1 AND Filter #2 AND Filter #3, and so on. You can also extend this logic with OR logical operators after each group.
AND logical operator example
OR logical operator example
Use the "contains" comparison to match a partial string of text.
Checking if a fact exists
The "exists" operator ensures that an auto-assignment will only run if the device fact has successfully reported to Addigy. This allows you to use your own custom device facts that may need to be deployed to the device before the policy is assigned.
Scoping to other policies
You may only want to target devices that are assigned to another policy (for example, those other policies can represent an organization or department). You can do this by selecting the "Policy IDs" fact, and clicking the Edit button to select any number of policies.
Now, your flex policy will target all devices in the selected policies. Any assets you add to the flex policy will now also be deployed to all the devices in the targeted policies.
Note: Selecting a parent policy automatically includes all of its child policies.
You can exclude any of the child policies by adding a second filter with the "does not contain" operator.
Testing Auto-Assignment Filters
Before saving a filter, you may want to test it to see which devices will be pulled into the policy once the automation begins.
Then you can view all devices that match that filter,
Disabling an Auto-Assignment
You can enable or disable any auto-assignment by toggling the button on the top. Any devices that were assigned to the policy previously will remain assigned. You can still manually assign devices to the policy, and Automated Device Enrollment will continue to work if it’s configured.
“Location” Policy
The policy_ids fact allows you to check each policy to which a device is assigned. With multiple polices now possible, it can be hard to keep track of the devices initial enrollment policy, which is often associated with a specific group, corporate department, or managed services client. To help make that simpler, we're identifying the original policy as the device’s location. In the Devices table, the original "Policy ID" fact is referred to as "Location":
You can also use the bulk action "Change Location" on any number of devices:
Deploying assets automatically
With an Auto-Assignment in place on a policy, any assets you add to the policy will be deployed to the devices described by the filter. These could be items from the catalog or software updates required by those devices.
Each time a device checks in (approximately every 30 minutes), Addigy will check its current state against any auto-assignments and assign the appropriate policies and deploy all management items configured in the Policy.
Additionally, if one of the policies is deployed via Policies > Deploy Now, all policies the device is a part of will be deployed to the device.
Additional Notes
- Devices will keep their original Push (APNs) Certificate, even if its policies change. It may change the other data visible on the Enrollment Profile, but the certificate is not changed.
- Read more about Flex Policy Use Cases