Policies explained

A policy is a collection of one or more configurations. Each policy can be applied to one or more devices at the same time. In addition, one or more policies can be associated with each device.

Create #

Policies are platform dependent. When creating them, care must be taken to determine which platform a policy is created for. For example, an iOS policy cannot be subsequently changed to an Android or Windows policy. Within the Apple operating systems, a distinction is also made between iOS, macOS, tvOS, visionOS and watchOS policies and likewise cannot be subsequently changed over.

In the side menu under Devices → Policies, there will be the overview of the policies that have already been created. One can create a new policy via the Add button. At this point, a target system must be specified and a name has to be given.

Clicking Save creates the new policy.

Policy Versioning #

All changes to a policy only take effect after a Publication. This process allows all configurations to be made and checked for completeness without the changes becoming active directly on linked devices.

Once all changes have been made and are ready to be applied to the devices, the version is published via the Publish button. The button is located in the action bar of the configuration list, to the right of Add. Only a version that has been changed since its creation and contains at least one enabled configuration can be published.

The menu of the Publish button offers two variants:

• Publish on all devices: The version is applied to all devices the policy is assigned to.
• Publish on test devices: The version is published as a test version (state Test) and is only applied to the devices of the device groups that use the test version. These device groups are selected in the following dialog, provided that no device group uses the test version yet. All other devices keep the previously published version. A test version can later be applied to all devices via Publish.

The Versions Sidebar #

The Versions Sidebar is used for a quick view of already published policies.

The following indicators are shown here:

• Pencil Icon (Pen): Marks the current Draft – this is the latest, but still unpublished version of the policy.
• Green Mobile Phone Icon: Identifies the currently published policy and thus the one applied to the devices.
• Blue Flask Icon: Identifies a test version that is only applied to the selected test device groups.
• Version Information: When publishing a new version, a Name and a Note (Description) can be specified. These are displayed directly in the sidebar to quickly document and track changes.

Version History #

For detailed tracking of all changes, there is also the Version History tab.

In this overview, all policy versions are clearly listed, including the following details:

The columns Modified by and Modified on are hidden by default and can be shown via the column selection.

Restoring Policies #

An older version of a policy is selected in the Versions sidebar (1) and restored as a new draft using the Restore as draft version button (2) in the policy header. Alternatively, the function is available on the Version History tab. After confirming with Restore (3), the current draft is replaced by a copy of the selected version; all unpublished changes are lost. The policy must have at least one other version besides the draft.

Priorities #

Policies have priorities. The lower number trumps the higher one. So priority 2 wins against priority 3. The priority number only applies within the same level: Global policies → always take precedence over policies shared by a meta organization →, and these in turn take precedence over the policies of the organization itself. A local policy with priority 1 therefore does not override a global policy.

Each platform has its own priority list. So there can be policies with priority 1 multiple times - each for iOS, macOS, tvOS, visionOS, watchOS, Android Classic/ Legacy, Android Enterprise and Windows.

If a configuration type that can only be created once per policy (e.g. the restrictions for Android Classic/ Legacy, Android Enterprise and Windows) occurs in several policies with different priorities, only the configuration from the policy with the highest priority is used. The configurations of the lower-priority policies are not merged, but ignored completely. If a function is allowed in the restrictions of a policy with priority 2, but prohibited in one with priority 4, it remains allowed.

Some of these configuration types, however, are transferred to the device from all policies together, e.g. the restrictions for iOS, macOS and tvOS; the device then applies the more restrictive setting in each case. Configurations that can be created multiple times (e.g. Wi-Fi or certificates) are combined from all policies. If two entries collide (e.g. Wi-Fi profiles with the same SSID), the one from the policy with the higher priority applies.

The priorities are changed in the policy overview via the 3-dot menu and the Change priority entry.

Global policies #

Now and then, it can be useful to be able to apply identical configurations in several organizations of Relution. To do this, global policies can be created and shared in the Global organization →. These policies can be edited normally in the Global organization, but are only available as read-only in the other organizations.

A published version of the policy is required for sharing. The policy is then selected in the overview and shared via the 3-dot menu with Set visibility to global (in the detail view of the policy: Set policy visibility to public). This sharing cannot be undone. In meta organizations →, Set visibility to meta is available accordingly; the policy is then available as read-only in all subordinate organizations.

In the overview, the Scope column shows whether a policy is shared: In the Global organization, shared policies are marked with Shared, in the other organizations with From Global (or From Meta for policies of a meta organization). Policies that are not shared are marked with Local only.

Deactivate Policies #

As of Relution 5.33, it is possible to deactivate policies for individual devices. Previously, device groups always had to be cloned and adjusted to temporarily remove a device from a policy assignment. This is now easily possible via Navigation → Devices → Inventory → the device → Policy. To do this, the corresponding policy must be selected and can be deactivated/activated via the 3-dot menu.

Policy Status #

The policy status is displayed in the header box on the device details page. The following statuses can occur:

• UNKNOWN = Problem

  • The status of the device policy is unknown

• NONE = None

  • No policy is applied to the device

• SENT = None

  • A policy has been assigned to the device, but it has not yet been applied

• APPLIED = Active

  • A policy is being applied to the device

• UPDATE = Active

  • A new version of the policy has been sent to the device, but the device has not yet updated it

• CHANGE = Info

  • Another policy has been sent to the device, but the device has not yet changed the policy

• REMOVED = Info

  • The policy has been unassigned from the device, but the device has not yet removed the policy