Naming Policy in Office 365: User and Admin Benefits

Post Date: 03/15/2018
feature image

What the naming policy in Office 365 means

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 ‘’. 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.

Make sure your Azure AD is free from clutter (outdated information, incorrect information) before using naming policy

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 Product Officer. In this role, he aligns product strategy with business strategy, leading the conception and design of software solutions with a focus on product market-fit and optimal customer value. Prior to this role, John has held several leadership roles over his 10+ year tenure at AvePoint, including SVP of Product Strategy, Director of Education, and Chief Technology Officer, Public Sector. Before coming to AvePoint, John held 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.

View all post by John Peluso

Subscribe to our blog