Wondering what you should avoid when building a provisioning solution in Microsoft 365? Microsoft MVP Drew Madelung shares his tips and tricks to help you keep a good focus.
When working on a provisioning solution in Microsoft 365, there are good and bad things to do.
Sometimes it’s easier to look at the things to avoid versus the best practices because every provisioning solution is different. What you’ll steer clear of suggests you may need to build something beyond the out-of-the-box capability. You want first to ask yourself if out-of-the-box tools can help you. If the answer is no, think about what’s best for your organization.
So what pitfalls should you avoid when building a custom provisioning solution? Let’s find out!
5 things to avoid in Microsoft 365 provisioning:
- Using technology your team can’t support
- Not getting actual requirements
- Too many approvals
- Only planning for modern SharePoint
- Not planning for change
1. (Avoid) Using technology your team can’t support
Building a custom provisioning solution for your collaboration workspaces in Microsoft 365 has a large toolkit of options.
If you’re building something incredibly custom at scale, you could be in a situation where you have custom code running somewhere like Azure or on a server that needs to be maintained and governed.
Many provisioning solutions are using Microsoft Patterns & Practices (PnP) provisioning engine. This can be used via PowerShell or development languages but can become complex.
What if your team doesn’t have anyone that can actually write or understand the development languages that the custom solution was written in? What if you hired a third party to build a solution in the Power Platform, but no one on your team has ever worked with it, and when it’s done, it breaks?
If your team is more comfortable with Azure Logic Apps than Power Platform and can get the same technical capabilities from the platform for the ask, then you should use it.
Ensure your technical architecture can be built, supported, and maintained after the provisioning solution is built. One of the worst scenarios is if you build something, there is an issue, and no one on your team has the skills to fix it. And just like that, your amazing custom Microsoft 365 provisioning solution you spent time and money to build is useless.
2. (Avoid) Not getting actual requirements
You need to make sure that you’re building or enabling a provisioning solution that has a reason to be there.
- Do you need to block creation for certain people or have a naming scheme for part of your organization? That is simply fine to have but don’t jump to conclusions for technical implementation based on the technology.
- A motto to live by when building your provisioning solution is “just because you can, doesn’t mean you should.” It’s too easy to fall into a complex solution because you think it’s a clever idea but, is it needed?
A common pitfall for collaboration workspace provisioning is an extremely complex naming scheme for Teams with a prefix. If you have too many characters at the beginning, let’s say you use a business unit or department, within the Teams clients, you won’t be able to determine the team itself, and you’ll only see a giant list of department names.
The takeaway: Just because you can make a complex prefix doesn’t mean you should!
Include non-IT stakeholders in your planning
The way to avoid this circumstance is to have stakeholders outside of IT in the planning and design sessions. For example, your information governance team might have good reasons to want to use Adaptive Scopes for retention policy or label deployment. Maybe your communication team wants a better information architecture for news and a better SharePoint hub site architecture as part of provisioning.
As you prepare to deploy fully, do user acceptance testing. Don’t just have functional IT testing as part of your implementation. While piloting the solution, use feedback surveys, focus groups, and meetings to talk to the users about the solution to hear what they like and don’t like. Spending the time upfront will ensure that your Microsoft 365 provisioning solution is not overly complicated and is what the users want.
3. (Avoid) Too many approvals
One of the worst things you can do for your users is slow down the collaboration experience.
If they’re requesting a SharePoint or team, they’re in the context of their work and will be more productive if they can get their workspace as quickly as possible. But if you put a barrier in the creation of an unnecessary approval, they’ll end up storing those files somewhere else like their own computer, a network share, or another cloud storage option, and end up emailing multiple copies around.
If they could quickly get their collaboration workspace, they’d have better sharing, security, compliance, and overall working experience.
This doesn’t mean that there aren’t reasons to have approvals in a provisioning solution.
Power Automate approvals
A great tool is Power Automate approvals. Only use them when appropriate. A good example is to include approvals for SharePoint and Team sites that are planned to host sensitive data or in regions that require Microsoft multi-geo. Then you can ensure you’re controlling risk and cost.
An effective way to think about this is to start your provisioning plan with open provisioning and only lock it down where you need to. Don’t start with approvals required for all and only open it up for a specific reason.
4. (Avoid) Only planning for modern SharePoint
Microsoft 365 provides a collection of collaboration solutions, and they continue to evolve. The primary collaboration solutions are backed by Microsoft 365 Groups, which power SharePoint, Teams, Yammer, Outlook, Planner, and maybe more in the future.
Even within SharePoint, we have group-backed sites and non-group-backed sites like Communication sites. As you have read through these things to avoid, you’ll see the references to Microsoft 365 collaboration workspaces, not just SharePoint or Teams.
Use the idea of what type of collaboration workspaces you need to provision with specific configurations to empower your users.
You can build a provisioning front end that lets the user pick the types of things they want to work on, and then provision the appropriate workspace.
For example, if a user is prompted with a collection of workspace options on creation, one could be document storage, the next a project site, and the other could be communication location. The first would provision a non-group-backed SharePoint site, the next would be a Microsoft Team, and the last would create a SharePoint communication site. This gives you a flexible, business-focused solution compared to just a technical SharePoint tool.
5. (Avoid) Not planning for change
Microsoft 365 is an evergreen solution. From the time this post is written to the time it’s read, there will be something that changed in your tenant.
A provisioning solution is not a set-it-and-forget solution. The workspace options will change, the capabilities you can configure will change, and the ability to add governance options as part of provisioning will continue to evolve. Also, the APIs backing Microsoft 365 continue to expand with more options and sometimes will have endpoints deprecated. Things will break and need to be maintained at the same time as innovative technology gets released.
Establish a proactive response to changes within your organization.
One of the best ways to do this is through the message center and the option to track your message center tasks in Planner. This will let you and your organization stay in front of changes before they break your provisioning solution and allow you to plan for updates if new options come out. If you built a solution using custom development or PnP open-source technologies, follow the Microsoft 365 developer blog.
Making the best decisions for Microsoft 365 provisioning
Every provisioning process will be slightly different. It’s hard to figure out the best practices for everyone so think about these things, from planning to ongoing maintenance.
- Using technology your team can’t support: Don’t build something so complex that no one can fix it.
- Not getting actual requirements: Don’t overcomplicate if it doesn’t need to be.
- Too many approvals: Start with no approvals and only add where needed.
- Only planning for modern SharePoint: Approach modern SharePoint as collaboration workspace provisioning.
- Not planning for change: Things will break and change, so be ready.
Check out the other articles in this series where I break down the Microsoft 365 collaboration architecture and how to get started with Microsoft 365 provisioning.