About profiles and policies
Last updated April 3rd, 2024
Profiles and policies in the new console are organized and structured quite differently from how they are in the original console.
Profile and policy terminology
The term policy has shifted from its original meaning in the original console and typical industry usage. The updated terminology for policies is as follows:
| Term | Nearest terms in the original console | Meaning in the new console |
|---|---|---|
| Profile | Profile |
The parent entity that consists of policies and settings that can be pushed to devices to alter their behavior. This definition hasn't changed from the original console. |
| Policy | Category |
A bundle of settings belonging to a specific category. On the console, rather than treating all policies as a unified payload, each policy is treated like a subset of the payload. This difference is a departure from the classical understanding of policies, but with the myriad number of policies for the most popular platforms — which in recent years is typically in the hundreds — this way of clustering settings with a similar purpose should significantly reduce the complexity and administrative burden of managing profiles of all sizes. |
| Setting |
Policy Sub-policy |
A property that alters behavior of the device by hooking into the management API of its OS. Previously, many customers reported confusion about the differences between a policy drawer, policy, and sub-policy. Rather than needlessly spending design resources on questions of taxonomy of that nature, simply referring to any individual property as a setting greatly simplifies the understanding of how policies are structured. |
For example:
In the original console, there is an Android policy called System > Camera, and another called System > System update. As far as the console is concerned, both of these policies are members of the larger, undifferentiated blob of settings that are pushed to a device, and have as much relation to each other as they do to the Location > Location accuracy policy. Any further properties belonging to these policies would be called sub-policies, regardless of how deeply-nested they are.
In the new console, the different semantic categories of policies are more tangible. The categories — System and Location — are instead the policies themselves, and the settings belonging to them, which were previously called individual policies, are now tightly tied together. Therefore, within the console, Camera is an inextricable setting belonging the System policy, and Location accuracy is a setting that belongs to the Location policy. The total number of policies is now much smaller, and their granular settings can more easily change as the Android platform evolves over time, without needing to frequently re-categorize them.
Reusable policies
One advantage of the new definition of policy is that it makes organizing the interface much easier, and allows the console to facilitate extra functionality to make policy management much faster.
With the new console, policies can be saved and reused in other profiles. It works like this:
- When you configure a policy, you have the option of giving it a name and saving its settings as a preset.
- When you configure that same policy type in another profile, you can load the preset, which restores all its saved settings.
- After you load a policy preset, you can then override specific settings within it, as required.
- After the profile is deployed to devices, you can further update the preset, and any profile that includes it would automatically receive its latest settings.
For example:
Let’s say your enterprise has an office with an isolated Wi-Fi network, and you maintain separate profiles for the finance, sales, training, and marketing departments. Among other settings, each profile pre-loads the SSID and password for the on-site Wi-Fi access points.
One day, the Wi-Fi password is changed for security reasons. Each department’s devices would need to be updated with the new password to continue working. In the original console, you would have had to individually edit each department’s profile, one by one, to achieve such simple a change.
In the new console, you could save the Wi-Fi settings as a shared policy preset. All you would need to do would be to add the new password to the policy, and every profile that includes the policy would automatically adopt the new password.
On this page
Is this page helpful?