Organization Groups

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.

• Build groups for entities within your organization (Management, Salaried, Hourly, Sales, Retail, HR, Exec, and so on).
• Customize hierarchies with parent and child levels (for example, ‘Salaried’ and ‘Hourly’ as children under ‘Management’).
• Integrate with multiple internal infrastructures at the tier level.
• Delegate role-based access and management based on a multi-tenant structure.

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.

Characteristics of Organization Groups

Organization groups can accommodate functional, geographic, and organization entities and enable a multi-tenancy solution.

• Scalability – Flexible support for exponential growth.
• Multi-tenancy – Create groups that function as independent environments.
• Inheritance – Streamline the setup process by setting child groups to inherit parent configurations.

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.

Considerations for Setting Up Organization Groups

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.

• Delegated Administration – You can delegate administration of subgroups to lower-level administrators by restricting their visibility to a lower organization group.

• Corporate administrators can access and view everything in the environment.
• LA manager has access to the LA OG and can manage only those devices.
• NY manager has access to the NY OG and can manage only those devices.
• System Settings – Settings are applied at different levels in the organization group tree and inherited down. They can also be overridden at any level. Settings include device enrollment options, authentication methods, privacy setting, and branding.

• Overall company establishes an enrollment against the company Active Directory server.
• Driver devices override the parent authentication and allow a token-based enrollment.
• Warehouse devices inherit the AD settings from the parent group.
• Device Use Case – A profile can be assigned to one or several organization groups. Devices in those groups can then receive that profile. Refer to the Profiles section for more information. Consider configuring devices using profile, application, and content settings according to attributes such as device make, model, ownership type, or user groups before creating organization groups.

• Executive devices cannot install applications and have access to the Wi-Fi sales network.
• Sales devices are allowed to install applications and have VPN access.

Changing Organization Groups

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.

Compare Two Organization Groups

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.

• Upload XML files containing the OG settings from different Workspace ONE UEM software versions.
• Eliminate the possibility of a difference in configuration causing problems during version migration.
• Filter the comparison results, allowing you to display only the settings you are interested in comparing.
• Search for a single setting by name with the search function.

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.

1. Navigate to Groups & Settings > All Settings > Admin > Settings Management > Settings Comparison.

   

2. 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.

3. Select the comparison OG on the right drop-down menu (labeled with the numeral 2).
4. Display a list of all settings for both selected organization groups by selecting the Update button.
   • Differences between the two sets of OG settings are highlighted.
   • You can optionally enable the Show Differences Only check box. This check box displays only those settings that apply to one OG but not the other.
   • Individual settings that are empty (or not specified) display in the comparison listing as ‘NULL’.

Create Organization Groups

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.

1. Navigate to Groups & Settings > Groups > Organization Groups > Details.

   

2. Select the Add Child Organization Group tab and complete the following settings.

   Setting	Description
   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.

3. Select Save.

Delete an Organization Group

You can delete an organization group (OG) provided it contains no OG children and no devices anywhere in its downline.

1. Move to the OG you want to delete by selecting it from the OG drop-down menu.

   

2. Navigate to Groups & Settings > Groups > Organization Groups > Details.

3. 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.

4. Once the counts for Devices in Organization Group and Child Organization Groups are both zero, then you can proceed with deleting the OG.

5. Select the Delete button.
6. The Restricted Action - Organization Group Delete screen displays and provides warnings about preparations you must take before deleting the OG.
7. Before you are allowed to proceed with the deletion, you must enter your four digit security PIN, which you selected when you enrolled as a UEM admin. Reset this PIN by selecting the Forgot Security PIN? link.

Identify the Group ID for Any Organization Group

You can identify the group ID for any organization group (OG) by taking the following steps.

1. Move to the OG you want to identify by selecting it from the OG drop-down menu.

   

2. Hover your pointer over the OG label. A popup displays the name and group ID for the currently selected organization group.

Inheritance, Multi-Tenancy, and Authentication

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.

BYOD users differ from Corporate users. Devices used by BYOD users belong to the users themselves and likely contain more personal information. So these device profiles might require slightly different settings. BYOD users might have a different terms of use agreement. BYOD devices might need different enterprise wipe parameters. For all these reasons and more, it might make sense for BYOD users to log into a separate OG.

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.

• All device profiles meant to apply globally to ALL devices, including compliance policies and other globally applicable device settings, are applied to two organization groups instead of one. The reason for this duplication need is that inheritance from Corporate users to BYOD users is no longer a factor in this model. Corporate users and BYOD users are now peers and therefore there is no inheritance.
• Another SAML override must be applied to BYOD users. This override is necessary because the system assumes it is inheriting SAML settings from its parent, Administrators. Such an assumption is a mistake because BYOD users are not administrators and do not have the same access and permissions.
• BYOD users continue to be handled separately from Corporate users. This alternate model means that they continue to enjoy their own device profile settings.

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.

Organization Group Restrictions

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.

• Whether you are in a software-as-a-service (SaaS) or on-premises environment, you cannot create nested customer OGs.

Organization Group Type Functions and Customizations

The type of an organization group can have an impact on what settings an admin can configure.

• Global – The top-most organization group. Usually, this group is called Global and has type Global.
  • For hosted SaaS environments, you are not able to access this group.
  • On-premises customers can turn on Verbose logging at this level.
• Customer – The top-level organization group for each customer.
  • A customer organization group cannot have any children/parent organization groups that are of the customer type.
  • Essential workflows can only occur within a customer type OG or within its hierarchy. These workflows include adding a device, register and enroll a device, user group mapping, smart group creation and mapping, changing the OG on a device (or moving a device from one OG to another), and device check-out.
  • Some settings can only be configured at a Customer group. These settings filter down to lower container type OGs.
    • Autodiscovery email domains
    • Device Enrollment Program settings (before AirWatch 8.0)
    • Personal content
    • Apple VPP (Volume Purchase Program), must be enabled at the parent customer OG and only then will child container type OGs feature working VPP functionality.
    • Samsung Enterprise FOTA
    • Hub packages
    • Custom attributes
    • Relay server
    • Intelligence
    • Sensors
    • App Scan and App Removal Protection
    • CDN (Content Delivery Network) for app delivery
    • NFS storage for content management will become configurable
    • Workspace One hub services
    • Conditional Access
    • MAG (Mobile Access Gateway)
    • LBUS (Local Basic User Sync)
    • Dynamic Environment Manager
    • Mobile Flows
• Container – The default organization group type.
  • All organization groups beneath a customer organization group must be of the container type. You can have containers between Partner and Customer groups.
• Partner – Top-level organization group for partners (third-party resellers of Workspace ONE UEM).
• Prospect – Potential customers. Similar to a customer organization group and might have less functionality than a true customer group.

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…

1. Navigate to Groups & Settings > Groups > Organization Groups > Types and then select the Add Organization Group Type button.
2. Enter the Name you want for the OG Type and its Description.
3. Select Save.

Reasons You Should Not Enroll Devices in Global

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.

Multitenancy

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.

Inheritance

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.

Functionality

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.

Override Versus Inherit Setting for Organization Groups

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.

Child Permission

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.

Current Setting

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.