This eBook takes an in-depth look at the permission settings in SharePoint, how they can be configured and how they affect multiple services in Microsoft 365. We also investigate the permissions used when flows run in Power Automate and how Power Automate can be used to modify permissions in SharePoint.
Understanding permissions in SharePoint and Power Automate are very important, and if you’re creating solutions that make use of these services, then you need to understand the permissions structure.
Even if you’re not creating your own solutions yet, if you are using Microsoft 365, the chances are that you are using SharePoint to store files even if you don’t know it yet. SharePoint is used as the document repository for a number of M365 services so, for example, if you store files in Microsoft Teams or Planner, these are actually being stored in the connected SharePoint site.
OneDrive, even though it is used for personal storage, is actually built on SharePoint technology. Also, the newest M365 service, Microsoft Lists, actually stores the lists it creates on SharePoint.
Permissions in SharePoint start off relatively simple when a new site is created, but it is possible to quickly find yourself in ‘Permissions Hell’. Permissions can be controlled at a very granular level so if people make changes to lists, libraries and individual documents you can end up in a situation where you have no idea who has access to what in your environment.
This book will take you through permissions in SharePoint and Power Automate. The aim is to show you how everything can be configured and help you avoid a situation where you lose control of permissions.
When you create a Communication Site, you can view the Site permissions by clicking the Settings cog in the top right-hand corner and then Site Permissions. As you can see from the image below, there are three SharePoint groups created by default – owners, members and visitors:
You can also configure the sharing options for the Site by clicking on Change how members can share. This allows you to control which groups of users can share files, folders and the Site as a whole. It also allows you to configure whether the Site allows access requests from users who want to view the Site and also specify who receives these requests.
To add users to your Site, you need to click Share site that as shown in the first screenshot. You can then enter the name of the user and give them a permission level of Full Control, Edit or Read. You can also send an automated email to the user with a custom message to let them know they’ve been added to the Site:
With the above example, John Doe would be added to the Site visitors group as he has been granted read permission:
If he was given Full Control, he would be added to the owner’s group, and Edit would put him in the member’s group.
The previous pages show the modern interface for configuring SharePoint permissions. However, if you click the Advanced permissions settings link you will be taken to the classic interface where additional permission settings can be accessed.
The first page of this section shows the same information about the default groups and their permission levels:
You can view more information about the different permission levels by clicking Permission Levels from the top ribbon menu:
Clicking a permission level name will then give you a full list of all the separate actions that this level allows a user to do:
You can change the permissions level used for a particular group by selecting the group and then clicking Edit User Permissions:
If you change a permission level for a group in this way, then when you go to the Site Permissions in the modern interface, you will no longer see the default three groups that were there originally:
If required, you can also add your own custom groups by clicking the Create Group button in the advanced permission settings:
You can specify settings such as the group owner, who can view and edit membership, joining requests and the permissions associated with the group:
Once the group is set up, you can then add the users you need, and this can include external users if your Site allows external sharing. If you want to include all users in your group, there is a built-in group called Everyone except external users.
If you do use this group though it may be worth unticking the Send an email invitation as otherwise, every user in your environment will receive an email (although in some cases this may be required):
Any custom groups created in this way won’t be displayed in the modern interface and have to be managed using the classic permissions settings area.
Another useful feature in the advanced permissions settings is the Check Permissions option:
Clicking this button allows you to check the permission levels given to a particular user or group. It displays any permission levels associated with the user and the permissions group that grants them:
It is good practice to use groups in SharePoint to assign permissions as it is easier to manage groups rather than individual users having permissions. For example, if a user changes department, you can remove them from any SharePoint groups they no longer need to be a member of rather than having to remove them from every individual location they had access to.
List and Library Permissions
By default, every list and library in a site inherits its permissions from the overall Site permissions. You can see this is the case when you go into the permissions for a library and see the message below:
If required, you can break this inheritance by clicking the Stop inheriting permissions button in the list or library settings:
Once you have broken the inheritance, you can then assign unique permissions to the library:
As well as setting unique permissions on a library, you can also set permissions on individual folders within the library. Clicking on the ellipsis next to a folder name and then Manage Access displays the permission settings for that folder:
Here there is also another link to take you to the advanced settings page, but this time it is for the specific folder:
As you can see from the above, by default the folder is inheriting permissions from its parent (in this case the library called Documents). Similar to the previous steps though you can click Stop inheriting permissions and then set unique permissions on the folder.
It is also possible to do the same on individual documents, so different documents can be accessed and edited by different users and groups. However, this is not recommended as it can be very difficult to manage permissions when they are set differently on multiple documents, especially in large libraries.
When you create a team site in SharePoint, you are also creating an M365 group, which it is attached to. When creating a team site, you will see some extra settings showing the group email address and privacy settings:
You will also see a step where you can add additional owners and members to the connected M365 group:
Once the Site has been created and you click on Site permissions you will see the same three default SharePoint groups just like the communication site, but if you expand the owners and members you will see that they are pre-populated with the owners and members of the connected M365 group:
You will notice that the permission for the member’s group can be changed between edit and full control. If you change it to full control, then the M365 group members group will be moved into the Site owners SharePoint group:
However, you cannot amend the permissions for the M365 group owners. They are hardcoded to be in the site owners SharePoint group, and this cannot be changed.
Another difference is the way you share the Site. When you click Invite people you get two options – Add members to group and Share site only:
If you add users to the group, then you can specify whether they are group owners or members:
As mentioned earlier SharePoint integrates with Microsoft Teams. When you create a Team, an M365 group is also created, which includes a SharePoint Team Site. Once you have created a team, you can see this is the case as when you go to the team settings you will see team owners and members which correspond to the associated group owners and members.
You will notice that in every channel in a team there is by default a Files tab:
You can see that there is a button labelled Open in SharePoint and this opens the underlying SharePoint site, specifically the location where the files for that channel are stored:
If you click on the link to take you to the top level of the library, you will notice that you are in the Shared Documents library and there is a separate folder for each channel in your team:
It is important to note that when you create a new channel in Teams, a corresponding folder will be created here automatically. However, if you manually create a folder here, it will not show up automatically in Teams. Files created or uploaded to existing channel folders in SharePoint will show up in Teams though.
When viewing folders and files in Teams, there are no options to change the underlying SharePoint permissions. To do this, you need to click the Open in SharePoint button, and then you will have access to the SharePoint permissions interfaces as discussed earlier.
Private channels are available in Teams, and they allow you to have channels that are only accessible by a sub-group of the team. In order to facilitate this, when you create a private channel a separate M365 group is created just for this channel. Users added to the private channel are automatically added to this group as well and this is used to manage the permissions for the channel.
As mentioned in the introduction to this book, OneDrive is actually part of SharePoint, and the interface is similar. You can see this is the case by opening OneDrive and looking at the URL:
Notice the my.sharepoint section of the URL. Every user’s OneDrive is essentially a personal SharePoint storage area that is only accessible by them. If users want to share folders or files in their OneDrive though they are able to do that. This is done by creating a sharing link for the document or folder, and there are two ways to do this:
Clicking Share opens a pop-out menu where you can enter the email address of the user you want to access your content:
Clicking Copy link either in the above box or using the Copy link ribbon button in OneDrive allows you to copy the sharing link so you can paste it into an email or Teams message:
In both of the above methods you can also change the settings of the link:
This includes setting who can use the link and whether they can edit the content or just view it. You can also set an expiration date so the link will automatically stop working after this date and also set a password to access the content if required.
An important thing to note is that this is slightly different to when you create a sharing link in a SharePoint site. By default, the option to select Anyone with the link (which is also called anonymous access as the person using the link doesn’t have to sign in) is disabled on SharePoint sites. However, this can be enabled by the SharePoint admin.
If you share a document in SharePoint you also get a couple of extra options to force the document to open in review mode only and also block the ability of people with the link to download the document:
Once you have created a sharing link, you can also go back into the document at a later date and remove them so anyone trying to access them using the links will be unable to. This will only stop people who use the link from accessing the document; users given direct access such as group owners and members will still be able to access it.
Any list created with Microsoft lists is actually stored on a SharePoint site. There is a quick setting in the advanced settings option of a list where you can control what items users can see:
You can specify whether users can view and edit all items in the list or only ones that they have created. Alternatively, you can make the list read-only by clicking the None option under Create and Edit access. If a user has full control permission on the Site or list though, they will see all items regardless of the settings you choose here.
Run Only User Permissions
The permissions used when power automate workflows run depend on the type of trigger that is used. If you set up an automated or scheduled flow, then the credentials of the user that created it will be used for any actions that run as part of the flow.
With an instant flow, however, the flow runs using the credentials of the user that initiates the flow. You can add users as run only users to a flow in the Power Automate designer, and these users will be able to run the flow but won’t have access to make any changes to it:
In the following example, we have a simple flow which can be run against a specific file in a library, and the user can add some comments and status. These are then used to update the properties of the file in question:
When John Doe runs this flow against a document, you can see that the modified by column shows John’s name, meaning that the flow ran under his account:
However, if you want the flow to run using the connection of one of the owners of the flow, you can change this. Clicking Edit in the Run only user’s section will show the following options where you can select an owner’s connection to use when running the flow:
If the connection is changed in this way it is important to note that the modified by details will show as the owner of the flow rather than the person who ran it.
Modifying SharePoint Permissions with Power Automate
It is possible to modify permissions on documents in SharePoint using actions such as the ones shown below:
At the time of writing these actions can only be run on documents or list items, and not on folders within the library or list.
You can also create a sharing link for a file or folder using power Automate. Currently, though, you can’t create sharing links for list items:
Using the REST API to modify permissions
The REST API has been a part of SharePoint for a long time and can be called within a flow to perform actions that may not be available as standard Power Automate actions. The following example shows how you can use this to modify permissions on a document stored in SharePoint.
The first step uses the REST API to get the user ID of the reviewer set in the document properties:
It then uses the Parse JSON action so the User ID can be extracted from the results:
Another RST API call is then used to break the inheritance of permissions on the document in question. If copyRoleAssignments is set to true then all existing permissions on the document are retained, if it’s set to false, then all permissions are removed. Only the person calling the REST API will be able to access the document if it’s set to false.
The following three examples show how you can also assign permissions to a document to a user, a group and also how to add a user to a group: