SharePoint provides several types of user permissions and roles, which can, in turn, cause a lot of confusion when trying to deploy any kind of custom product in your environment.
Moreover, the correlative permissions will, inherently, depend on where you're trying to deploy the products (i.e, Classic SharePoint sites).
To overcome this barrier, this article will focus on all the required roles and/or permissions that need to be granted to a specific user, in order to make sure that the deployment process goes smoothly.
Before we begin
Let's get one specific permission out of the way!
The higher permission level, which can be granted to a user is that of a Global Administrator, having control over all facets of your Office365 infrastructure (i.e, SharePoint, Azure, Teams, etc). Typically, users who are granted this superuser privilege will be able to deploy any type of custom product without the need for further permission configurations.
This being the case, if you find yourself being granted this permission, be sure to stop reading here.
However, most use-case scenarios will need to further delegate any role and/or permissions, in order to sub-divide the workload. If that's true in your organization, you'll find detailed information on what it is you need to deploy BindTuning products!
Let's talk about installation methods
As you're most likely aware, BindTuning provides several deployment methods to accommodate any enterprise-related policy and/or security concert. This being the case, we could subdivide our installation processes:
- Automated installation - Which will deploy the corresponding products automatically, using our built-in provisioning agent:
- BindTuning Online App - Allows for the deployment of BindTuning products to infrastructures on Office 365, comprehending deployments to both SharePoint and Microsoft Teams;
- BindTuning Desktop Application - Allows for the deployment of BindTuning Products on SharePoint On-Premises, as well as SharePoint Online.
- Manual installation - Powering the user to download and manually add any BindTuning product to their infrastructure.
With this same subdivision, we are ready to start exploring the needed permissions, given a number of constraints and/or policies you may have in place, further deciding how to deploy your products.
BindTuning Online App
The BindTuning Online App constitutes an easy-to-use and hassle-free deployment method. To proceed with the installation, BindTuning needs to be granted access which will, in turn, sit on your Azure Enterprise Applications dashboard.
This being the case, the installation will only start, if the user who's proceeding with the installation is either an Azure Administrator or, in turn, has the role of Application Admin.
As soon as BindTuning has been registered as one of your Enterprise Applications, no further dependencies remain, meaning that a user who does not have the above-mentioned permissions, will be able to proceed with the installation, considering the SharePoint-side permissions are in place.
BindTuning Desktop Application
Unlike the BindTuning Online App, no pre-installation conditions are in place. This being the case, the usage of the tool will only require that the concrete SharePoint permissions are in place.
The manual deployment does not possess any pre-deployment conditions, being only dependent on the SharePoint permissions in place.
Let's talk about the Classic Experience
BindTuning's products (i.e, themes, web parts, etc.) are deployed at the Site Collection Level, under your Solutions Gallery page.
This being the case, and considering you want to deploy the products to a Classic site collection, you'll necessarily need to be a Site Collection Administrator for that same site collection, in order to successfully install the products
Let's talk about the Modern Experience
Unlike the installation for Classic sites, the Modern SharePoint experience can be centralized and/or decentralized, depending on your own necessities.
BindTuning products for the Modern SharePoint experience can, as allowed by SharePoint, be deployed on either Tenant App Catalog or Site Collection App Catalogs.
Note: If you'd like to learn more about the necessity of an App Catalog for Modern-type site installations, as well as how to proceed with its creation, click here.
Tenant App Catalog Deployment
A deployment to the Tenant App Catalog will centralize the installation process. This being the case, any product deployed to the Tenant App Catalog will be accessible on any Modern Site Collection, removing the constraints of having to deploy the products on a site collection to site collection basis.
The creation of the Tenant App Catalog site collection needs to be performed manually and can only be done by a Tenant (SharePoint) Administrator. As soon as the creation process has been performed, any user who has Contribute access to that same site will be able to further deploy and/or modify existing solutions.
This type of deployment will make sure the users are able to add BindTuning products to their own site collections, as long as they have the concrete Edit permissions, as appliable on any type of modification.
Site Collection App Catalog Deployment
Instead of deploying the products to the entirety of your Tenant, and considering you to be on Office 365, you'll have the ability to restrict the scope of the installation. This being the case, each Modern site collection can contemplate its own Site Collection App Catalog, to where you'll be able to further deploy custom applications.
Note: Keep in mind that, whereas the Tenant App Catalog is created once per tenant, you can have as many Site Collection App Catalogs as Site Collections themselves.
The creation of the SharePoint Site Collection App Catalog will happen automatically if using any of the BindTuning Automated Installation methods but will, alternatively, need to be created via PowerShell if choosing the manual deployment method route.
Much like for the Tenant App Catalog, only a SharePoint Administrator is able to create Site Collection App Catalogs. However, after its creation, a user who has Contribute access to the corresponding site collection will be able to deploy custom applications.
To ensure a more uniform deployment experience, for both of the scenarios above, we recommend the user performing the installation to be a SharePoint Administrator. This way, we're able to tailor the installation without recurring to more granular control mechanisms.
Let's talk about Microsoft Teams
BindTuning's Microsoft Teams Add-On applications are built on top of our web part (Build) solutions for SharePoint. This being the case, the deployment of the applications for Microsoft Teams will require the applications to be added to either the Tenant App Catalog or, alternatively, Site Collection App Catalog.
Moreover, by default, custom applications are disabled on your Teams Admin center. In order to make sure the applications are able to be successfully deployed, this policy needs to be changed by a Teams Administrator.
As soon as both the constraints are fulfilled (from a SharePoint and Teams perspective), the installation will proceed as expected.
Let's have a look at real use-case scenarios, where we'll be able to more concretely layer the necessary permissions:
User A is a Global Administrator for an Office 365 infrastructure. User A is trying to deploy BindTuning products automatically, but wanting them to be available on the entirety of the tenant.
Given the above-mentioned constraints, we can proceed with the following flow:
- Considering User A is trying to deploy the products to Office 365, we can utilize BindTuning's Online App;
- User A is a Global Administrator, which makes it an Azure Administrator by proxy, so the required permissions are in place;
- User A wants to deploy to the entirety of the Tenant. Being a GlobalAdmin it is, by default, also a SharePoint Tenant Admin, making it possible to deploy the products.
User B is a SharePoint Administrator for its company Office 365 infrastructure, wanting to deploy products to a specific site collection. User B has requested several types of added permissions but was not granted them.
- Considering User B is trying to deploy the products to Office 365, we can utilize BindTuning's Online App;
- Being that the user is a SharePoint Admin and, likewise, is not able to request further permissions, the application does not pass the required Azure constraints;
- User B is left with the installation using the Desktop Application or, manual installation procedure;
- User B created (if it does not exist) a Tenant App Catalog, as it possesses the required permissions;
- Being that user B wants to install the products to only one site collection, it needs to create a Site Collection App Catalog;
- If User B opted for the Desktop Application, the Site Collection App Catalog is created automatically;
- If User B opted for the manual installation, the Site Collection App Catalog needs to be created manually.
BindTuning potentiates several deployment methods, accommodating distinct permission levels. This article focused on the several paths that may need to be taken into consideration when trying to deploy any custom application to your SharePoint and/or Office 365 environment.