Think of organization groups as individual branches on a family tree, with each leaf as a device user. Workspace ONE UEM identifies each leaf and establishes its standing in the family tree using organization groups (OG). Most customers make OG trees look like their corporate hierarchy: Executives, Management, Operations, Sales, and so forth.
You can also establish OGs based on Workspace ONE UEM features and content.
You can access organization groups by navigating to Groups & Settings > Groups > Organization Groups > List View or through the organization group drop-down menu.
Note: The Organization Groups List View defines “Active Devices” as only those devices that have reported back to the Workspace ONE UEM console within the prior 8 hour period.
Organization groups can accommodate functional, geographic, and organization entities and enable a multi-tenancy solution.
Using the example of the organization group drop-down menu, profiles, features, applications, and other MDM settings can be set at the ‘World Wide Enterprises’ level.
Settings inherit down to child organization groups, such as AsiaPacific and EMEA or even further down to grand-child AsiaPacific > Manufacturing or even great grand-child AsiaPacific > Operations > Corporate.
Settings between sibling organization groups such as AsiaPacific and EMEA take advantage of the multi-tenant nature of OGs, by keeping these settings separate from one another. However, these two sibling OGs do inherit settings from their parent OG, World Wide Enterprises.
Alternatively, you can opt to override settings at a lower level and alter only the settings that you want to change or keep. These settings can be altered or carried down at any level.
Before setting up your organization group (OG) hierarchy in the Workspace ONE UEM console, first decide on the group structure. The group structure allows you to make the best use of settings, applications, and resources.
You can change organization groups by selecting the OG indicator at the top-right of the screen.
When selected, a drop-down menu displays your OG hierarchy, allowing you to change to another organization group.
You can compare the settings of one organization group to another to mitigate version migration issues. The Organization Group Compare feature is only available for on-premises customers.
You can perform the following tasks when you compare OG settings.
An example of a version migration scenario is when a User Acceptance Testing (UAT) server has been upgraded, configured, and tested, you can compare the UAT settings to the production settings directly.
Navigate to Groups & Settings > All Settings > Admin > Settings Management > Settings Comparison.
Select an OG in your environment from the left drop-down menu (labeled with the numeral 1). Alternatively, upload the XML settings file by selecting the Upload button and selecting an exported OG setting XML file.
You must create an organization group (OG) for each business entity where devices are deployed. Understand that the OG you are currently in is the parent of the child OG you are about to create.
Navigate to Groups & Settings > Groups > Organization Groups > Details.
Select the Add Child Organization Group tab and complete the following settings.
|Name||Enter a name for the child organization group (OG) to be displayed. Use alphanumeric characters only. Do not use odd characters.|
|Group ID||This required OG identifier is used by end users during device login and during the enrollment of group devices to the appropriate OG.
Ensure that users sharing devices receive the Group ID as it might be required for the device to log in depending on your Shared Device configuration.
If you are not in an on-premises environment, the Group ID identifies your organization group across the entire shared SaaS environment. For this reason, all Group IDs must be uniquely named.
|Type||Select the preconfigured OG type that reflects the category for the child OG.|
|Country||Select the country where the OG is based.|
|Locale||Select the language classification for the selected country.|
|Customer Industry||This setting is only available when Type is Customer. Select from the list of Customer Industries.|
|Time Zone||Select the time zone for the OG’s location.|
You can delete an organization group (OG) provided it contains no OG children and no devices anywhere in its downline.
Move to the OG you want to delete by selecting it from the OG drop-down menu.
Navigate to Groups & Settings > Groups > Organization Groups > Details.
At the bottom of the Details screen, review the counts for Devices in Organization Group and Child Organization Groups. If either entry is not zero, then you cannot delete the OG and the Delete button is unavailable.
You must move all devices from this OG into another OG. Any child OGs downline of the OG you want to delete must also contain no devices before they can be deleted.
Once the counts for Devices in Organization Group and Child Organization Groups are both zero, then you can proceed with deleting the OG.
You can identify the group ID for any organization group (OG) by taking the following steps.
Move to the OG you want to identify by selecting it from the OG drop-down menu.
Hover your pointer over the OG label. A popup displays the name and group ID for the currently selected organization group.
The concept of overriding settings on a per-organization group basis, when combined with organization group (OG) characteristics such as inheritance and multi-tenancy, can be further combined with authentication. This combination provides for flexible configurations.
The following organization group model illustrates this flexibility.
In this model, Administrators, generally in possession of greater permissions and functionality, are positioned at the top of this OG branch. These administrators log into their OG using SAML that is specific to admins.
Corporate users are subservient to administrators so their OG is arranged as its child. Being users and not administrators, their SAML login setting cannot inherit the administrator setting. Therefore, the Corporate users’ SAML setting is overridden.
And while not subservient to Corporate users in a corporate hierarchy sense, placing BYOD users as a child of Corporate users has advantages. This arrangement means that BYOD users inherit settings applicable to ALL corporate user devices by applying them to the Corporate users OG.
Inheritance also applies to SAML authentication settings. Since BYOD users is a child of Corporate users, BYOD users inherit their SAML for users’ authentication settings.
An alternate model is to make BYOD users a sibling of Corporate users.
Under this alternate model, the following is true.
What factor determines which model is the best? Compare the number of globally applicable device settings with the number of group-specific device settings. Basically, if you want to treat all devices in generally the same way, then consider making BYOD users a child of Corporate users. If maintaining separate settings is more important, then consider making BYOD users a sibling of Corporate users.
If you attempt to configure an organization group (OG)-limited setting, the settings pages under Groups & Settings > All Settings notify you of the limitation.
The following restrictions apply to creating Customer-level organization groups.
The type of an organization group can have an impact on what settings an admin can configure.
There are additional Organization Group types such as Division, Region, and the ability to define your own Organization Group type.
Add Organization Group Type
You can add custom organization group types. These types do not have any special characteristics and function identically to the Container Organization Group type.
To create your own OG type…
There are several reasons enrolling devices directly to the top-level organization group (OG), commonly known as Global, is not a good idea. These reasons are multitenancy, inheritance, and functionality.
You can make as many child organization groups as you need and you configure each one independently from the others. Settings you apply to a child OG do not impact other siblings.
Changes made to a parent level OG apply to the children. Conversely, changes made to a child level OG do not apply to the parent or siblings.
There are settings and functionality that are only configurable to Customer type organization groups. These include wipe protection, Telecom, and personal content. Devices added directly to the top-level Global OG are excluded from these settings and functionality.
The Global organization group (OG) is designed to house Customer and other types of OGs. Given the way inheritance works, if you add devices to Global and configure Global with settings intended to affect those devices, you are also affecting all the Customer OGs underneath. This undermines the benefits of multitenancy and inheritance.
The hierarchy of the organization group (OG) structure you make determines which OGs are children and which are parents. Child OGs inherit settings from their parent OGs but you can elect to override this inheritance.
Each system settings page applies its settings according to two types of inheritance / override options regarding organization group hierarchy: 1) Current Setting and 2) Child Permission. The OG it applies settings to is the OG you are currently in.
In other words, if you are in the Employees\Warehouse OG, then changes you make to settings apply to that OG and all OGs that are children of the Warehouse OG.
For example, the Branding settings page, found by navigating to Groups & Settings > All Settings > System > Branding, controls all the custom background images, logos, and color schemes for the OG visible in the organization group drop-down.
Applying our example earlier, you can import a new background image, new logo, a different color scheme, all specific to the Employees\Warehouse OG. You can also configure the settings to apply to the Warehouse OG only. This option is enabled by changing the inheritance of this OG on the settings page.
Think of the Child Permission setting as the parent OG’s attitude toward the child OG. There are three different settings for Child Permission: Inherit or Override, Inherit Only, and Override Only.
The Inherit or Override setting simply means that the parent has no preference for the child’s permissions. When a parent’s Child Permission setting is Inherit or Override, the Current Setting of the child OG determines whether they override or inherit settings. Child Permissions are set to Inherit or Override by default.
A Child Permission setting of Inherit Only on the parent forces inheritance on all children. This setting means that all children have the same settings as the parent. A Child Permission setting of Override Only removes the inheritance effect on all child OGs, requiring you to configure settings specific to that child OG.
Child Permission settings affect only the children one level down. Such settings have no impact on grandchildren or lower OGs.
If Child Permission is the attitude of the parent toward the child, then the Current Setting of an OG is the attitude of the child toward the parent. A Current Setting can only be Inherit or Override.
A Current Setting of Inherit means that the child OG accepts all the settings of the parent OG. Select a Current Setting of Override, and the child rejects the parent and is on its own. The override selection means you can make new settings for the child.
You can only change an OG’s Current Setting provided the parent OG’s Child Permission setting is Inherit or Override.
Continuing the example from above, if you wanted to affect Branding settings to the Warehouse OG only, you can change the Current Setting for each child OG of Warehouse to Override provided the Child Permission for Warehouse is the default Inherit or Override. You can then configure Branding settings for the children of Warehouse as you see fit, either different from Warehouse or the same.
Changing Permission Settings
You cannot change the Current Setting of a child if its parent’s Child Permission setting does not allow it. For example, if MomandDadOG’s Child Permission setting is Override Only, you cannot change the Current Setting of JuniorOG to Inherit. In short, the parent OG’s Child Permission settings take precedence over the child OG’s Current Setting.
When you change the Current Settings of a child from Override to Inherit, changing the Child Permission setting of its parent to Inherit Only locks the child OG’s Child Permission setting. You are not able to change the child permission setting in this scenario. This behavior does not apply if the child OG setting is never overridden.
The work-around to this behavior is that you must change the Child Permission settings on the parent OG back to Inherit or Override, unlocking the Child Permission setting of the child OG.
The larger, preferred strategy is to plan ahead, configuring inheritance and override settings to the OG levels that make sense given the hierarchy structure you want.