Product Documentation

User Communities

Jan 12, 2017

Every organization consists of diverse user communities that operate in different functional roles. These user communities perform different tasks and office functions using various resources that you provide through the users' mobile devices. Users may work from home or in remote offices using mobile devices that you provide, or using their personal mobile devices, which allows them to access tools that are subject to certain security compliance rules.

As more and more user communities start using mobile devices to either simplify or aid in their job role, Enterprise Mobility Management (EMM) becomes critical to prevent data leak and to enforce an organization's security restrictions. In order for efficient and more sophisticated mobile device management, you can categorize your user communities. Doing so simplifies the mapping of users to resources and ensures that the right security policies apply to the right users.

The following example illustrates how the user communities of a healthcare organization are classified for EMM.

Use Case

This example healthcare organization provides technology resources and access to multiple users, including network and affiliate employees and volunteers. The organization has chosen to roll out the EMM solution to non-executive users only.

User roles and functions for this organization can be broken into subgroups including: clinical, non-clinical, and contractors. A selected set of users receive corporate mobile devices, while others can access limited company resources from their personal devices. In order to enforce the right level of security restrictions and prevent data leak, the organization decided that corporate IT manages each enrolled device, Corporate and Bring Your Own Device (BYOD). Additionally, users can only enroll a single device.

The following section provides an overview of the roles and functions of each subgroup:

Clinical:

  • Nurses
  • Physicians (Doctors, Surgeons, and so on)
  • Specialists (Dieticians, phlebotomists, anesthesiologists, radiologists, cardiologists, oncologists, and so on)
  • Outside physicians (Non-employee physicians and office workers that work from remote offices)
  • Home Health Services (Office and mobile workers performing physician services for patient home visits)
  • Research Specialist (Knowledge Workers and Power Users at six Research Institutes performing clinical research to find answers to issues in medicine)
  • Education and Training (Nurses, physicians, and specialists in education and training)

Non-Clinical:

  • Shared Services (Office workers performing various back office functions including: HR, Payroll, Accounts Payable, Supply Chain Service, and so on)
  • Physician Services (Office workers performing a variety of health care management, administrative services, and business process solutions to providers, including: Administrative Services, Analytics and Business Intelligence, Business Systems, Client Services, Finance, Managed Care Administration, Patient Access Solutions, Revenue Cycle Solutions, and so on)
  • Support Services (Office workers performing a variety of non-clinical functions including: Benefits Administration, Clinical Integration, Communications, Compensation & Performance Management, Facility & Property Services, HR Technology Systems, Information Services, Internal Audit & Process Improvement, and so o.)
  • Philanthropic Programs (Office and mobile workers that perform various functions in support of philanthropic programs)

Contractors:

  • Manufacturer and vendor partners (Onsite and remotely connected via site-to-site VPN providing various non-clinical support functions)

Based on the preceding information, the organization created the following entities. For more information about delivery groups in XenMobile, see Deploy resources in the XenMobile product documentation.

Active Directory Organizational Units (OUs) and Groups

OU

OU

Groups

XenMobile Resources

Clinical

XM-Nurses

XM-Physicians

XM-Specialists

XM-Outside Physicians

XM-Home Health Services

XM-Research Specialist

XM-Education and Training

Non-Clinical

XM-Shared Services

XM-Physician Services

XM-Support Services

XM-Philanthropic Programs

XenMobile Local Users and Groups

Group

Users

Contractors

Vendor1

Vendor2

Vendor3

Vendor4

Vendor5

Vendor6

Vendor7

Vendor8

Vendor9

Vendor10

XenMobile Delivery Groups

Clinical-Nurses

Clinical-Physicians

Clinical-Specialists

Clinical-Outside Physicians

Clinical-Home Health Services

Clinical-Research Specialist

Clinical-Education and Training

Non-Clinical-Shared Services

Non-Clinical-Physician Services

Non-Clinical-Support Services

Non-Clinical-Philanthropic Programs

Delivery Group and User Group mapping

Active Directory Groups

XenMobile Delivery Groups

XM-Nurses

Clinical-Nurses

XM-Physicians

Clinical-Physicians

XM-Specialists

Clinical-Specialists

XM-Outside Physicians

Clinical-Outside Physicians

XM-Home Health Services

Clinical-Home Health Services

XM-Research Specialist

Clinical-Research Specialist

XM-Education and Training

Clinical-Education and Training

XM-Shared Services

Non-Clinical-Shared Services

XM-Physician Services

Non-Clinical-Physician Services

XM-Support Services

Non-Clinical-Support Services

XM-Philanthropic Programs

Non-Clinical-Philanthropic Programs

Delivery Group and Resource Mapping of Apps

 

Secure Mail

Secure Web

Secure Notes

ShareFile

Receiver

SalesForce1

RSA SecurID

EpicCare Haiku

Epic Hyperspace

Clinical-Nurses

X

X

X

X

 

 

 

 

 

Clinical-Physicians

 

 

 

 

 

 

 

 

 

Clinical-Specialists

 

 

 

 

 

 

 

 

 

Clinical-Outside Physicians

X

 

X

X

 

 

 

 

 

Clinical-Home Health Services

X

 

X

X

 

 

 

 

 

Clinical-Research Specialist

X

 

X

X

 

 

 

 

 

Clinical-Education and Training

 

 

 

 

 

 

 

X

X

Non-Clinical-Shared Services

 

 

 

 

 

 

 

X

X

Non-Clinical-Physician Services

 

 

 

 

 

 

 

X

X

Non-Clinical-Support Services

X

 

X

X

 

 

 

X

X

Non-Clinical-Philanthropic Programs

X

 

X

X

 

 

 

X

X

Contractors

X

 

X

X

X

X

 

X

X

 

Delivery Group and Resource Mapping of MDM Resources

 

MDM: Passcode policy

MDM: Device Restrictions

MDM: Automated Actions

MDM: WiFi policy

Clinical-Nurses

 

 

 

X

Clinical-Physicians

 

X

 

 

Clinical-Specialists

 

 

 

 

Clinical-Outside Physicians

 

 

 

 

Clinical-Home Health Services

 

 

 

 

Clinical-Research Specialist

 

 

 

 

Clinical-Education and Training

 

 

 

 

Non-Clinical-Shared Services

 

 

 

 

Non-Clinical-Physician Services

 

 

 

 

Non-Clinical-Support Services

 

 

 

 

Non-Clinical-Philanthropic Programs

 

 

 

 

Contractors

 

 

 

X

Notes and considerations:

  • XenMobile creates a default delivery group named All Users during the initial configuration. If you do not disable this Delivery Group, all Active Directory users will have rights to enroll into XenMobile.
  • XenMobile synchronizes Active Directory users and groups on demand using a dynamic connection to the LDAP server.
  • If a user is part of a group that is not mapped in XenMobile, that user cannot enroll. Likewise, if a user is a member of multiple groups, XenMobile will only categorize the user as being in the groups mapped to XenMobile.
  • In order to make MDM enrollment mandatory, you must set the Enrollment Required option to True in Server Properties in the XenMobile console. For details, see Server Properties.
  • You can delete a user group from a XenMobile delivery group by deleting the entry in the SQL Server database, under dbo.userlistgrps.
    Caution: Before you perform this action, create a backup of XenMobile and the database.

About Device Ownership in XenMobile

You can group users according to the owner of a users' device. Device ownership includes corporate-owned devices and user-owned devices, also known as bring your own device (BYOD). You can control how BYOD devices connect to your network in two places in the XenMobile console: in Deployment Rules and through XenMobile server properties on the Settings page. For details about deployment rules, see Deploy resources in the XenMobile documentation. For details about server properties, see Server Properties in this handbook.

By setting server properties, you can require all BYOD users to accept corporate management of their devices before they can access apps, or you can give users access to corporate apps without also managing their devices.

When you set the server setting wsapi.mdm.required.flag to true, XenMobile manages all BYOD devices, and any user who declines enrollment is denied access to apps. You should consider setting wsapi.mdm.required.flag to true in environments in which enterprise IT teams need high security along with a positive user experience, which comes from enrolling user devices in XenMobile.

If you leave wsapi.mdm.required.flag as false, which is the default setting, users can decline enrollment, but may still access apps on their devices through the XenMobile Store. You should consider setting wsapi.mdm.required.flag to false in environments in which privacy, legal, or regulatory constraints require no device management, only enterprise app management.

Users with devices that XenMobile doesn't manage can install apps through the XenMobile Store. Instead of device-level controls, such as selective or full wipe, you control access to the apps through app policies. The policies, depending on the values you set, require the device to check the XenMobile server routinely to confirm that the apps are still allowed to run.