A new naming policy feature in Office 365 has been released in public preview, and its already working to make life easier for admins and end users alike. This naming policy applied to the name of the group as well as its alias.
Naming policy benefits to the end user
For the end user, this is useful for a few reasons. First, there are very few native mechanisms that let you know what a group is without having to go in and look around inside it, so the fact that a company can enforce a policy, it gives more context of a group. It’s useful that just the naming of a group can help a user understand it better because everything is very flat. If someone names a group “sales effort,” it’s tough to really know anything about the group. You don’t know where the creators of that group are, the region the group applies to, etc.
For example, I work in AvePoint’s Arlington office. Let’s say I want to see all the groups that are in the Arlington location. With this naming policy, I could search for the prefix that all the Arlington groups have and instantly know all the Arlington groups.
From the admin side of things, this naming policy is a big help too. One of the risks is that the group name becomes part of things like the URL where your notebook lives or the URL your SharePoint site lives in.
When you have a Team or a Group, the name is very important because the URLs are going to be that group. Let’s say you have a global organization and the IT team for a particular office decides they’re going to create a group called ‘IT.’ If they’re the first ones to create the group, they essentially own the URL ‘company.com/teams/IT’. They’re not the global IT team but it looks like they are based on the URL.
Naming policy benefits to IT Admins
This ability to control the ID of the group, which factors into the URLs is very important from an admin perspective. Also, the naming policy feature allows admins to establish custom blocked words lists. This allows admins to set policies that say ‘nobody is allowed to create a group called IT or information technology.
One thing to consider with this naming policy is the fact that it’s a one-size-fits-all. All the groups and teams that get created always follow the same naming convention. This can be good or bad.
Naming Policy is only as effective as your Azure Active Directory
Additionally, the naming policy will only work to its full effect if your AD information that becomes part of the prefix or the suffix is accurate for your users. Otherwise, you’re going to get a lot of wonky names that are actually wrong, because the feature blindly pulls from what’s already in the AD profile.
Also, the naming policy will ALWAYS reference the requestor, which may or may not be appropriate, especially if the requestor is creating the group or team for another user or department.
For example, users have information in AD like their manager, region or an office already in your profile. If you have a user who switches offices – say they’re moving from D.C. to Manhattan – and that information wasn’t updated, it would actually have the wrong location if that was being used as a prefix or suffix.
So, in addition to considering the health of your AD, price is another component to bear in mind. This naming policy feature requires an Azure Active Directory premium licensing, so there is a cost per user consideration associated with the feature.
This new feature can go a long way towards getting your organization’s use of Groups and Teams as buttoned up as possible. However, it’s also good motivation to do that audit of your Azure AD that you’ve been putting off. With a good, clean, up-to-date AD, this naming policy feature can save headaches, time and extra work for your team.
For more news, tips, and information, be sure to subscribe to our blog to keep up!
John Peluso is AvePoint’s Chief Technology Officer. In this role, he aligns the Company’s technology and product roadmaps to grow AvePoint’s market share, and accelerate the ideation, development, and launch of innovative software products tailored to anticipate customer needs. Prior to this role, John held multiple leadership roles over his 13-year tenure at AvePoint, including Chief Product Officer, SVP of Product Strategy, Director of Education, and Chief Technology Officer, Public Sector.
Before joining AvePoint, John served in a variety of technology and business roles at New Horizons Northeast and New Horizons of Central and Northern NJ. He earned his undergraduate degree from The New School.