Groups…  It’s a term every business user consuming technology has heard at some point in time.  Most users only experience groups when they’re unable to access a specific application or file and the coworker sitting next to them informs them they need to call IT and get added to the department group.  Those of us who work on the technology side of the fence are very familiar with the benefits groups bring to the table when controlling access to data.  We are also quite familiar with the challenges they can bring when managing them at scale.

Something as simple as a lack of an enforced naming convention can create serious pain for an organization if it relies heavily upon the naming convention to determine the function and owner of a group.  The pain bleeds through IT and into the business as workers struggle with long wait times for on-boarding new employees due to IT trying to determine which groups the users need to be in.  When it comes time to perform an access review, business owners may waste valuable time trying to determine if removing an employee from a specific group will impact that employee’s ability to fulfill their job responsibilities.

In the on-premises world organizations deal with the challenge of naming conventions in different ways.  Most rely upon first or second level help desk to create groups according to the organization’s naming standard.  This method introduces the risk of human error and presents challenges when the group information for a particular application is sourced from a variety of different identity backends which force the staff to learning multiple tools.  Others make use of identity management (IDM) systems that automate the creation of groups and enforce the naming convention.  This method is very effective but also very costly due to high costs in implementing and operating an IDM.  A very small minority of organizations have evolved to the point where the naming conventions are no longer important due to robust reporting systems and entitlement databases.

Very few organizations are able to successfully execute the third method, which leaves them with the first or second.  The introduction of the software-as-a-service (SaaS) has made the first and second methods of enforcing a naming convention much more complicated.  Using the first method of leveraging help desk staff to create the groups manually is no longer scalable and the second method of using a centralized IDM system is often limited by the vendor’s ability to write connectors to the wide variety of APIs in use across the thousands of SaaS vendors.  All is not lost, as it seems some vendors have begun to recognize the challenge this can introduce to their customers.

If your organization is a consumer of Office 365, you’ve more than likely begun to use Office 365 Groups.  Office 365 groups offer a variety of features not found in the traditional security/distribution group or shared mailbox.  Take a look at this link for a comparison chart that documents the features.  One important thing to note is Office 365 Groups can only be only created in Azure Active Directory (AAD).  You cannot synchronize an on-premises Active Directory Domain Services security or distribution group to AAD and convert it to an Office 365 Group.  This means you can’t leverage an existing solution for enforcing naming conventions unless that solution has a connector into Azure AD.  Given features Office 365 provide and that they are the construct used by Microsoft Teams, you may make the decision to allow your users to create Office 365 Groups on the fly in order to allow them to take full advantage of collaboration tools available in Office 365.  To quote Peter Venkman, “Human sacrifice, dogs and cats living together… mass hysteria!”.

Calm down my friend.  Microsoft has a solution coming in the pipeline that will solve your Office 365 Groups naming convention woes.  In my next post I’ll demonstrate the feature and walkthrough how to test the feature out while it is in preview.