Whether it’s a device used for navigating during a route, or a health care worker using a device to communicate with others while on a shift, company assigned devices have become a crucial part of operations while on the job.

Some workers rely on a series of applications that help them get the job done. But each app requires user authentication to access critical information directly relating to their role and responsibilities

Every shift, users spend unproductive time logging in to each app.

Do to the architecture of MobiControl, IT Admin would need to relocate towards 5 touch-points in the product to get Shared Device with Single Sign-On up and working in no particular order; Profiles to configure Feature Control; Apps Policy to configure Microsoft Authenticator with Shared Device and SSO capabilities; Microsoft 365 to provide the device access to Microsoft applications; Directories to properly configure user groups with the application needed for these features; and Shared Device configuration to bind everything together.

To allow the system access to features necessary to perform Single Sign-On and Shared Device mode on the devices, a connection to the required APIs needs to be established through the use of a unique identifier. To ensure that all required settings and data are properly connected, this unique Tenant ID must be placed in three areas within the full configuration workflow.

Those that will be using SSO and Shared Device mode are our end users, but those who would be configuring this feature for them would be IT Admin within their oganization. As another user segment for this feature, they require a simple and seamless experiencee as well. With other similar features, the product would have the user relocate to other areas within the product to get all the pre-requisites set up. As we pushed to have the entire configuration under one location, the team needed the senior stakeholders to green light our flow to this "one-stop-shop" solution.

With all the dependency issues that may come up from allowing our new "one-stop-shop" configuration modal to send the application capable of SSO down to the device, we decided to keep it separate and guide the user to this configuration later if the system realizes that they do not already have it.

In reality, this new consolidated setup is a collection of setup environments that already exists across the product, tucked neatly into one modal. Therefore, if a change happens in one of these environments outside of the modal, this would then be reflected within the modal, and vice-versa. With this concern, the architecture team requested that we make a clear distinction between the "promisable" (data not affected by external changes) and "non-promisable" (data fetched from other areas within the product) areas within the configuration, to help prevent IT admin from making a change that may break this configuration.