Posts

Automating Site Provisioning and Governance in Office 365

What is Site Provisioning? 

Site Provisioning is a process of creating SharePoint sites programmatically to meet business requirements.  

Site Provisioning deeply impacts both governance and site sprawl, and for that reason, it is one of the most important aspects of any Office 365 implementation. Nowadays, with more and more companies adopting Office 365, provisioning becomes increasingly relevant as it helps maintain structure in the digital workplace. This presents a whole new set of challenges for  IT and Office 365 administrators as they need to understand what are best methods for provisioning sites, teams and groups? How to ensure new sites, teams and groups fulfill governance criteria? And, finally how to automate the provisioning process? In this article we will address all of these questions.

Table of Contents

  1. How Site Provisioning affects governance 
  2. The benefits of automating site provisioning in Office 365 
  3. Automated provisioning: Real life example
  4. SharePoint site provisioning methods 
  5. How to automate the site, team or group provisioning process in Office 365 

How Site Provisioning affects governance 

Sites are the main structural element of SharePoint. There are different types of sites that organizations can use as a template to create their custom site structure. They may include classic sites, communication sites, team sites, publishing sites etc. In the previous versions of SharePoint on-premises, creating a new site was somewhat complicated. Nowadays, SharePoint Online lets us create a new site effortlessly through a simple 2-step process which, at least in theory, can be triggered by anyone in the organization. Users just need to navigate to the SharePoint site (/_layouts/15/sharepoint.aspxand click on + Create site” and that’s it.  

Create a site in SharePoint

However, this ease of use creates a problem. If users can create new sites on a whimeven a well-maintained internal site structure will soon turn into a messy, hard to manage bulk. 

Before we discuss the solutions, letexplain the difference between Site Provisioning processes in SharePoint on-prem and in Office 365 

In SharePoint on-premise, provisioning applies only to sites. However, in Office 365 this process applies to all structural elements of applications that make up the large modern work space: teams and channels in Microsoft Teams, channels in Microsoft Stream, and groups in Office 365. Considering the collaborative nature of all these tools, its easy to imagine that the sheer volume of Team, Channel and Group requests could quickly overwhelm the administrators.  

The benefits of automating provisioning in Office 365

There are numerous benefits to automating the provisioning process in Microsoft workplace collaboration apps, but the real game changer here is a truly enforceable governance. In a typical organization, governance policies live in a shared document. Employees refer to it from time to time, however the policies contained within are difficult to enforce across the organization. Keeping your governance documents up to date is rarely enough. By automating site provisioning processes with wizards or workflows, you’re helping employees do their jobs without worrying about non-compliance. 

Automated provisioning significantly reduces the chances of a human error. In fact, when automated, site or team provisioning on the front end is as simple as following an intuitive wizard that guides employees through the process, while ensuring business logic.  

Here’s how automated provisioning helps your organization: 

  • Sites, teams, channels are created by users in a self-serve system that follows business logic specific to your organization. 
  • Employees follow a step by step wizard that ensures new sites and teams adhere to corporate policies. 
  • Automation decreases the burden on your Office 365 administrators.    
  • The metadata that employees input during the process, helps manage the life cycle of the new site, team or channel. This means that deciding whether a site needs to be kept or retired becomes much easier.  
  • Automated site provisioning allows you to also automatically create reports, audits and site/channel directories.  
  • The process uses established APIs. 
  • Additional functionality (e.g. updating a site life cycle database) can be added easily. 

Automated provisioning: Real life example

Here we’ll show you a provisioning process we have been recommending to our clients. This particular process leverages PowerApps and Power Automate (formerly Microsoft Flow).  

  1. User requests a site and completes a form wizard filling it with required metadata. This information can include owner, purpose, description, related projects, cost centre, start date, end date, and template.  
  2. Application uses the metadata to create a team site based on the selected template. 
  3. Information from metadata helps manage the sites in the future. For example, information offered in the cost center is synced with internal accounting systems, end date and is used to ensure that there are no orphaned (or unused) sites. Team site owner becomes responsible for managing the team site’s life cycle. 

This approach lets you regain control over your Office 365 by ensuring that all sites, channels and groups follow the prescribed life cycle. By automating the process, you’re ensuring that new sites are added to a corporate site structure and, if needed, to a corporate site directory.  

This diagram explains a typical automated site SharePoint provisioning process we recommend:  

automated SharePoint site and Teams provisioning for Office 365

While our example focused on provisioning a SharePoint team sites, the same approach can be applied to provisioning Teams, Stream, and Office 365 Groups.  

SharePoint site provisioning methods 

Our automated provisioning process for Office 365 applications combines a set of provisioning methods that I’ll describe below. You can use each one of these stand-alone methods to provision sites in your organization. However, before you get started with any of them, consider you organization’s particular policies and restrictions to decide what’s the best fit for your organization.   

Provisioning a SharePoint Site using the User Interface 

There are a couple of ways to do this. The most obvious one is by enforcing Governance and applying settings to your tenant to limit the ways users can create a Team site (with or without an Office 365 Group). 

In this scenario, after clicking the SharePoint icon in the Office 365 App Launcher (often referred to as the Waffle Icon)the user opens SharePoint in a browser clicks on Create Site.
 App Launcher Office 365

Our next method is creating an Office 365 Group. User creates an Office 365 Group in Outlook by clicking on the New Group link. Each new Office 365 Group automatically creates a SharePoint site. 

Create a New group in Outlook

Good governance is critical if you’re using this method, as members of an Office 365 Group can soft delete a group (sometimes by accident). Without safeguards in place, the IT department won’t know this happened. To prevent this situation, you can set up a requirement to evaluate Office 365 Group deletions before they can be permanent. The deleted group is retained but not visible for 30 days from the deletion date. You can view and manage the deleted Office 365 groups that are available to restore by signing into the Azure AD Admin Center. 

Lastly, a SharePoint Admin can create a site in the new SharePoint Admin Center. 

 create a site in the SharePoint Admin Center

Provisioning using Microsoft Graph 

Using the Create Group API in Microsoft Graph will result in the creation of either an Office 365 Group. By default, an Office 365 Group is integrated with a bundle of Office 365 services. Currently, the Create Group API does not have the option to enable Microsoft Teams. If you require to include Microsoft Teams in your provisioning processthen you will need to execute an additional API in Microsoft Graph to enable Microsoft Teams on an Office 365 Group. When provisioning using the Microsoft Graph approach, you are creating a Team site via the creation of an Office 365 Group. 

Provisioning using REST API Operations 

If you’re looking for a more scalable Site Provisioning process, REST API Operations is one worth considering. With REST API Operations you create a SharePoint site based on a defined Site Template.  

SharePoint Admin Center - Site Template

Some of the most used site templates are Team sites and a Communication sites, but you can also apply other templates to provision a site using REST API Operations.  

Provisioning using PnP CSOM Core Component 

Another way to provision a site in SharePoint is by installing the Core library, which is available as a NuGet PackageThis method allows to develop the provisioning of a team site programmaticallyYou can get your core library NuGet packages for your SharePoint version below: 

Provisioning using PnPowerShell 

Like PnP CSOM Core Component, SharePoint developers can also provision sites using PnP PowerShell. With this approachyou create a PowerShell script to apply a provisioning template to a site. 

You can automate either of these approached with the help Power Automate (previously known as Flow), Logic AppsAzure Functionsand/or Web Jobs. Power Automate and Logic Apps are best for simple site provisioning operations, whereas Azure Functions and Web Jobs work well for more complex site provisioning operations. Here are some examples of complex site provisioning operations:  

  • Enabling web parts or custom actions (SPFx extensions) 
  • Creation of pages 
  • Creation of Content Types and Columns 

Automated Site Provisioning – The DevFacto Solution 

DevFacto has developed solutions that are constructed using all of the approaches listed above. One of our recent solutions developed for a client, calls APIs from Microsoft Graph and REST Operations automated via Microsoft Power Automate. Microsoft Graph is used to provision the Office 365 Group (which includes a site) and then the site is customized by calling additional REST Operations. 

Power Automate - Create O365 Group

Used the “HTTP” action (which is considered a PREMIUM connector)

This method allows to enable Microsoft Teams on the Team site. To accomplish that, we included it in the provisioning process by calling Microsoft Graph again. You can do that too by applying “/team” at the end of the URI to enable Teams to an Office 365 Group. Optionally, you can customize the Team by modifying the Body property (see next screenshot) with additional channels to be created, installation of apps, pinned tabs using delegated permissions, and defining Member/Guest/Fun/Messaging/Discovery settings for the new Microsoft Teams team. 

Power Automate -Enable Teams

Used the “HTTP” action (which is considered a PREMIUM connector)

Site Scripts and Site Designs are used to apply site artifacts and security principals to siteYou can determine the exact actions to be executed in the Site Scripts and Site Designs. Initiate Discovery workshops by analysing the business requirements of particular groups within your organization.   

ower Automate -Apply Site Designs

Used the “Send an HTTP request to SharePoint” action (which is in the SharePoint connector)

Alternatively, users can apply a site design to a site through the SharePoint UI. 

SharePoint Site Provisioning-Apply Site Design

 

 

Summary 

Whether your organization is new to Office 365 or has been using it for quite some time, you will need a provisioning process to ensure that new sites, teams, channels and groups are created in an orderly fashion. There are many good ways to manage the provisioning process, including low-tech ones. Some smaller organizations can get away with using their established IT ticketing system and that’s completely fine. However, growing needs and complexity drive other organizations to automating the provisioning process as it significantly improves efficiency and significantly reduces management costs.  

Automated provisioning ensures that governance rules are followed, while greatly improving application security and user experience. It also provides you with a wealth of metadata that’s collected during the provisioning process making it easier to maintain and administrate sites, channels, teams and groups well into the future.  

Automating the provisioning processes requires an upfront development investment. However, you can significantly reduce the associated costs by leveraging the tools you already have. Power Platform (PowerApps and Power Automate) apps we used in our example are included in most Office 365 subscriptions. What’s more, these tools come with many preconfigured low-code and no-code elements that fit together like LEGO bricks to give you more flexibility and more custom experience. 

Looking to get started with automating your Office 365 provisioning process? Get in touch.   

This article was written by Oliver Wirkus and Adam Tobias

References 

1) User Adoption Matters – How to Succeed with Your Office 365 Rollout 

2) Migration Pitfalls – Site-Provisioning 

3) Manage modern SharePoint sites using REST  

4) Choose the right integration and automation services in Azure 

5) Provisioning “modern” team sites programmatically 

6) Microsoft Graph  Create a team 

 

5 Master Data Management Myths You Can Stop Believing

There are many exciting topics under the Data Management umbrella, but if I had to choose one that resonates with me the most, I’d go with Master Data Management (MDM). Why? Because  MDM programs can enable any organization to realize the value of one the most crucial assets: data.

Master Data Management is a hot topic in the IT industry. However, many organizations are on the fence about implementing it due to the wide impact of changes and a relatively high rate of MDM project failures. Yet, despite this, developing a comprehensive MDM strategy should be a priority for modern, data-driven organizations.

In my two decades of work in the data management space, I’ve noticed that even though MDM has gained considerable traction, isn’t always well understood. In this post, I’ll share and hopefully debunk the most common myths that surround it.

But before diving in, let’s review the fundamentals of MDM.

Master Data Management is a framework that allows organizations to generate uniquely identifiable, business critical data. This data is often referred to as an “entity”. In essence, MDM makes corporate data an integrated, harmonious whole by continuously bringing together source data, assessing its quality and ironing out the inconsistencies to solve data-related business problems.

Now that we established what MDM is, let’s explore what it isn’t.

Myth #1: Master Data Management is a software.

Too often, we see that MDM is perceived as a software solution, when it really is a framework. Unfortunately, no software can handle the entire MDM framework right out of the box. Many vendors will pitch their product as the ultimate, holistic system, but what they don’t tell you is that MDM software is just an accelerator.

Of course, there is an undisputed value in MDM software, especially when it comes to simplifying and expediting certain elements of the master data management program such as Identity Resolution, Automation, Survivorship, and Remediation. However, approaching vendors to find what is available on the market shouldn’t be the first step when planning an MDM program.

While tools can certainly help or hinder MDM efforts, a successful MDM implementation is not made or broken by a tool. The real key to effective MDM lays in identifying fundamental elements of the program and carefully designing the implementation roadmap. Planning early on will increase the probability of MDM implementation success and will help avoid unnecessary software spend.

Myth #2: MDM can be done in silo

Organizational silos and resulting data silos are generally not conducive to effective data management operations.

Let’s take a financial department of a large manufacturing enterprise. This department takes in information from a couple of different financial systems which leads to duplicated and inconsistent data. Organization’s CFO decides to run MDM solely for the finance department focusing specifically on the “client” entity. As a result, this newly implemented MDM solution generates unique client records within the financial systems. It all looks good until a client contacts the company to change his address. Although the change is promptly reflected in the CRM, the financial systems remain untouched. Even though the client received his product, the invoice never arrives since it was sent to the old address.

Successful MDM requires that we track our chosen data entity across the ENTIRE organization, without exceptions. If, as per above example, client data is in 80% of departments, then we need to incorporate ALL of them into the solution.

Myth #3: Master Data Management is expensive

Because MDM is typically an enterprise scale project, it’s automatically associated with large investments and significant effort. As with any large-scale project, the strain on corporate resources is hard to predict and can go well beyond the initial estimates. In the presence of multiple risk factors (broad scope, high impact of changes, technology that’s new to the organization), MDM projects can be loaded with uncertainty. However, there are ways to mitigate the risks and pave way for success. One of the best ways to do it, is by phasing MDM implementation based on criticality of data entities and their prevalence across the organization. This approach helps companies validate the program with a small budget, while still offering value to the organization.

For example, rather than focusing on a major data entity that’s widespread across the organization, companies can drastically reduce the risk by starting with a “smaller” and less critical entity. For many organizations, “employee” is a good test entity to use as a proof of concept. Not only is it less prevalent across the enterprise than much more critical entities such as “customer” or “product”, but it also offers a good starting point for further program expansion.

A gradual, iterative approach to MDM alleviates the risk of failure, improves adoption and sets the program up for success when rolled out on a large scale.

Myth #4: MDM can be successful without Data Quality

In my experience, enterprises are very confident in Data Quality across their systems, until that’s put to the test. In most cases, Data Quality is lacking, and the organization is rarely fully aware of it. There are two main reasons why this happens:

  1. There is no such thing as perfect data. Data Quality rules are based on current business needs and subjective decisions about quality of data, therefore it is hard to achieve and maintain a state where data is perfect.
  2. Data is constantly changing, and live data tends to bring inconsistencies. So, data quality is only a threshold of at which the quality reaches an acceptable level.

Before embarking on an MDM implementation, it’s vital to address critical data discrepancies between existing systems. This can mean, for example, standardizing the way you specify state or province names across all systems (i.e. picking between an abbreviated name “AB” or a full name “Alberta”). Without proper Data Quality, records will remain separate and potentially create false-negative scenarios.

Myth #5: MDM is best left to IT

Assigning MDM implementation to IT might seem like an obvious choice. After all, the project will deal with both data and software systems. And while IT department is one of the major MDM stakeholders, and responsible for technical implementation, MDM is also about solving specific business problems. When IT is assigned to establish MDM, business tends to get less involved. This means that even though technology is handled, business needs may not be fully addressed. This can lead to low MDM adoption.

Due to wide scope and reach of MDM, the program should be centrally organized, overseen by a committee and implemented by a well represented, cross-functional team across the entire organization.

Are you ready for MDM?

Each year, the amount of data enterprises gather and produce increases exponentially. But without a structured organizational approach to data management, not only does the data diminish in value but also poses liability risks when mishandled. MDM can do a lot more for an organization than just reduce these risks – it can actively help realize the full potential of data by establishing an enterprise-wide state of data clarity.

Curious about Master Data Management, but don’t quite know where to start? Contact us today and we’ll walk you through the steps for adapting the framework in your organization.

A Tale of Two Governances – Part One: Health Benchmark

When you read about governance, it is often focused on what I call the “foundational governance”.  In the case of information technology we focus on foundational information governance, or the way we intend to use our information within the organization. Read more

ECM Governance – Part Five

In this post, I will finish off the definitions of the different principles and then we can move on from there to venture more in-depth about ECM governance. Read more

ECM Governance – Part Four

In this post, we continue the description of different categories of guiding principles for a SharePoint implementation (note that these are not the only categories as some may need to be added or removed depending on the purpose of the solution).

Read more

Assessing Your SharePoint Maturity

I find a common challenge with SharePoint is identifying where to go with it or what to do next. What is the greatest opportunity on which to focus your efforts?

Read more

ECM Governance – Part Three

In my last post, we examined the idea of guiding principles and how they are used to set a foundation for our ECM. We identified several categories or “Areas of Impact” that these principles could be separated into and next, I would like to start by detailing the intent of each of those categories.

Read more

ECM Governance – Part Two

In this post, I would like to continue along with the ECM governance work we previously started and delve further into the core of what defines governance: guiding principles.

If you want to consider implementing governance of any type, you are going to need to define a foundation on which to build rules for how things will be governed. Read more

ECM Governance – Part One

If you were ever looking for a main cause for the failure of SharePoint implementations, look no further than ECM Governance.  Over the next couple weeks I am going to share some insights I have experienced with governance of enterprise content and what organizations need to do to ensure the successful implementation and use of solutions like SharePoint and OpenText Content Server. Read more