The following content is the third part of a series of posts relating to an ongoing scenario. The previous posts in this series can be viewed using the links below:
- Nintex Workflow Document Submission: Introduction
- Part 1 – Making use of item check out and check in
- Part 2 – Checking in items automatically using a deadline
Although this is part of a larger scenario, each post can be suitably viewed separately for those that would like to view this for the general concept.
Using Office 365 actions in Nintex Workflow for Office 365
In Nintex Workflow, there are some actions that I was new to, which are the actions that begin with the words “Office 365”. Although these actions are documented by Nintex, it took me a while to get to grips with their configuration.
This blog should help you to gain a better understanding of how they are used and configured correctly, assisting you in incorporating them into your own workflows.
In today’s blog we will concentrating on the “Office 365 update item permissions” action as I’m sure this is useful in many business scenarios, as well as being the next step in this series’ ongoing workflow.
We are looking to change the item permissions for the current item so that the creator of this item can only view the file once the deadline has been reached, prevented any further changes from occurring. In a real world scenario, you may want to do something similar with an entire SharePoint group as opposed to an individual, which can also be achieved.
Firstly, add the action to your workflow. I will then begin talking about the common configuration settings for these similar Office 365 actions. These may be confusing to some at first glance, as they were with me, but they should become clear as we go through.
Common Office 365 settings
The first 2 settings in the configuration are the “Destination site URL” and “List name”.
For the destination site URL, it doesn’t hint at how specific it needs to be or how it needs to be formatted.
This value should be the root URL of where the list in question exists. For me, it does actually live in the root site, and therefore I can simply type it out in full as a string such as https://example.sharepoint.com
This means that you can target any SharePoint site, not just your current one!
For those that are only looking to use the current site, there is a super easy way for you to add this value without even knowing it! When in the configuration settings for the action, use the ‘Advanced Lookup’ feature to select the “Workflow Context” option, followed by “Current Site URL” and then clicking Insert.
Now, the “List name”.
This is where I had a bit of confusion. I’m sure that this is simply because I am from a programming background and therefore look deeper than I should, but I shall clarify this value for those with the same assumptions as me (probably not many of you!).
I looked at the actual name of the list that is contained in the URL, for example I thought https://example.sharepoint.com/Shared Documents would be “Shared Documents”, but the value you are looking for is the exact text of the general List Name found in the settings as below, that which you named the list, which is sometimes not necessarily the same as the name contained in the URL.
As with the “Destination site URL”, if you are only working with the current list that the workflow is being ran within, you can use the Advanced Lookup feature to select the “List Name” from the “Workflow Context” options.
Now, the other common settings should be straight forward, but here is some guidance for those that need it. These settings are the following:
- SharePoint Online URL
The SharePoint Online URL is the root URL of the entire SharePoint tenant, i.e. there should be no forward slashes after the initial URL address, for example https://exampleurl.sharepoint.com
Next, the Username and Password should be the credentials of the user that is able to perform the operation in question. The username would be the email address of the user, the same format that you also use to login to the SharePoint tenant.
These should be the main settings that are frequently used across that particular set of Office 365 based actions.
Update Item Permissions settings
Now I will cover the remainder of the important settings used to configure this action.
The “Items to update” field allows you to select the right options to target the file or files that you would like.
In my workflow, I am aiming to update the current item only, and below is how I achieved this.
Using the “Update items only when the following is true” filter, I selected the item where the field named “ID” is equal to the ID of the current item (selected using the List Lookup feature).
There are a few other settings as illustrated below.
You can select whether the permissions are still inherited from the parent, and whether to remove any existing permissions on the item before adding the new ones, all simply by selecting “Yes” or “No” from the corresponding drop down option box.
With the “Target” option, you can select whether you are targeting an individual user or an entire group to change the permissions for.
From the “User or group name” option, enter the name of the user or group that you are editing the permissions for.
Personally I have not yet fully tested the possibilities of the above field such as how the value would be formatted in plain text. Instead, I make sure that the value is being read directly from an existing value of a “Person or Group” type column using the “List Lookup” feature, or, like illustrated above, the “Initiator” from the “Workflow context” options.
The last option is “Permission”, which is as simple as selecting the required SharePoint permission level to be assigned to the configured target.
When the workflow is published and ran, the permissions will be set to those that were configured in the action.
The next post in this series will go through the next step of the workflow, adding an approval process.