This post was originally published at Users, Devices and Applications – How They Relate in UEM Architecture

In my previous article on How to uniquely identify a Device on UEM I briefly covered relationships between a device, its OS, its hardware and how they are recorded on UEM.  But the relationship between device, and user (or users), applications and other items on UEM is also sophisticated, so I thought I would expand out on how it all works.

Users and devices

UEM is designed so that developers who want to programmatically interact with it can leverage the REST APIs.  As of UEM 12.8, these are a rich set of APIs, but you will notice GUID (Globally Unique Identifier) all over the place when making calls.  GUIDs are assigned to various attributes by the server.  So, while GUIDs themselves are mathematically unique, they are only guaranteed unique for an organization’s set of servers.  Note that an “ID” and a “GUID” are considered interchangeable in the docs unless called out otherwise.  So UserID or UserGUID means the same value.

Let’s start with how a Server is identified.

Each UEM server, after installation, is assigned an SRPID (also known as tenant ID on the UEM server) by BlackBerry on your account, displayed as your “OrgID” within the Servers section when you are logged in.

Your licenses are typically user based, but can also be assigned by device, possibly both.   They are tied to your OrgID, like the UEM server tenant ID’s are.  So, all licenses can be used on one or more UEM servers, until they run out or expire within the Organization.

The first relationship to note is:

TenantID <> License <> users <> devices.  Where <> represents a many to many relationships.

On an Individual UEM server, it looks like this:

TenantID < users
TenantID < devices

Or one TenantID can support 1 or more users, 1 or more devices.

To keep track of users and devices, the server will assign a GUID when they are first seen.

So TenantID < userGUID and TenantID < deviceGUID.

Since a user can have multiple devices, then userGUID < deviceGUID.

However, this is where it starts to get fun.  A device has 2 different identifiers on UEM. One represents the devices hardware (its UDID, IMEI, MACaddress, etc), deviceGUID, and one is a representation of the user’s workspace on that device, userDeviceGUID.  It’s called this because a device profile is tied to a user, as well as a physical device.  The userDeviceGUID exists because some devices allow multiple user profiles (like Windows 10, MacOS, and later versions of android), so one device can have multiple users, each with their own device profile.

Here is an example REST call:


This call wants to get a specific device user’s workspace so you must supply the tenantID, the userGUID, the userDeviceGUID, and it will return the deviceGuid (and all the other info you want).

UEM lets you specify which users should be grouped together in a group. For example, it can assign a GroupGUID to a user, an activation profile for users, and assign a profileGUID, and so on for various attributes.


Applications are identified in a few diverse ways by UEM. They have a native ID such as bundleID on iOS, package name on Android and so on.  If it is built using our BlackBerry Dynamics SDK, it will be assigned a containerID by BlackBerry during its first Authorization process.  An Application GUID is assigned by UEM when the application is first recorded on the UEM server.  This can occur when you add the application to the UEM server.

It’s important to note that the relationship between ApplicationGUID : ContainerID is 1:1 across that UEM server.

Starting with UEM 12.8 you can send commands to BlackBerry Dynamics Applications using their ApplicationGuid:

POST /tenantGuid/api/v1/users/userGuid/userDevices/userDeviceGuid/applications/appGuid/commands

With such commands as “BLOCK_APPLICATION”

See more here.

Managed vs Unmanaged devices.

Another key aspect of UEM servers is the ability to manage applications on the devices that it doesn’t manage.  You do this by adding apps to an app list and entitling them to a user account, user group or device group.  Since the device is not managed, the user of the device must install the application.

For more information on Managing apps with UEM, go here.

Here is a list of terms to help you when working with users, devices and applications:


An “ID” and a “GUID” are considered interchangeable unless noted.

Created by Description notes
SRPID / tenant ID/ tenantGuid Unique to each UEM instance
appGuid UEM ID assigned to application by UEM
profileGuid UEM ID of a profile
directoryId MS AD MS SID, unique across domain
deviceGuid UEM ID assigned to device Hardware
groupGuid UEM ID assigned to UEM groups
userGuid UEM ID of the user device If device can have multiple users, each
user is assigned a separate device guid, hence userDeviceGuid
emailTemplateGuid UEM ID of the email template
activationPasswordGuid UEM ID of the activation password Will expire

See original article here:  

This post was originally published at Users, Devices and Applications – How They Relate in UEM Architecture