Skip to main content
Nintex Community Menu Bar

I appear to come across the same scenario time and time again.  A request of some sort is made.  It goes through one or multiple lines of approval.  Whilst it is in the approval process the item is set to read only so that no amendments can be made while it is in review.  Upon final approval, the item/document is updated to reflect the approved/rejected status.  The permissions on the item at that point do not allow for this update.  Or upon approval an item is added to another list that the “initiator” does not have access to contribute to.  So I thought I would discuss the different options that can be used for dealing with permissions inside a workflow:

Set item permissions

This action allows you as the workflow designer to decide to inherit or create unique permissions on the current item on which the workflow is running.  This works well in state machine workflows where the permissions at each state need to change (i.e. the current approver needs the ability to update an item whilst everyone else only has read access).  You can choose to inherit the permissions from the parent or stop inheriting as well as choosing to keep or delete any current item permissions (i.e. when someone needs adding to the permissions at a certain point).

SetItemPermissions.PNG

Pros

I like this action because you can define exactly which roles/people/groups can have access to an item at any given time during the workflow process.

Cons

If a workflow fails for whatever reason the permissions stay at the most recent set item permissions action.

It is difficult to control permissions to lists when the items have item level permissions.

 

Run as Workflow Owner

The action set action allows us to choose a configuration option of “Run as workflow owner”.  This means that all actions inside the action set container will run under the permissions of the account which published the running workflow.  This is a great workaround when you know that you have God-like permissions to do everything on your farm and don’t want to give any users access to certain lists of libraries.

ActionSet.PNG

Pros

Saves using the Set item permissions action and doesn’t impact on the item level permissions of the item the workflow is running on

Cons

This doesn’t work inside a state machine workflow; only a sequential workflow.  So if you are running a large process that you have designed with a state machine where the final approval means an item update, you cannot access the “Run as workflow owner” checkbox inside action set when it is placed on a state machine branch.

Created By and Modified By are always the same person for all instances of the workflow.  When running as workflow owner the credentials of the person who published the workflow are used.  This means that any items created or updated are effectively done by that person so you cannot quickly see who ran the workflow in the first place (and if you work in a blame culture, you will find people quickly asking you why you updated or modified an item!!).

If the workflow publisher leaves then the credentials and permissions will no longer work.

 

 

Call web service

An alternative way to deal with inserting and updating items without giving the initiator access to do so is to use web service calls which can run as a specified account.  As long as the account the web service is using has the permissions to perform the actions you are asking of it then there are no worries around who the initiator is and what permissions they may have.

Call Web service.PNG

Pros

Do not have to worry about the permissions that the initiator may have to perform the insert or update required.

Cons

A lot trickier to configure to achieve the same result.  I find that the Call web service action quite tiresome (because I don’t use it very often) so have to read up on what services and methods to use and spend a lot of time testing.

Again, if the account that the web service is using becomes locked out or deleted then the workflow will fail.

 

There are a lot of options for dealing with permissions in workflow.  I lean more heavily to the Set item permissions action although it doesn’t sit comfortably with me.  I would be really interested to hear your approaches here so please leave some comments and I may well revisit and update this blog post with your best practices.   happy.png

Excellent stuff Cassy Freeman​

With the option to "Run as Workflow Owner" in an Action Set, it might be worth creating a Service Account that is used when this specific requirement comes about. Using this Service Account to actually perform the Publish, would mean that you negate the issue of the publisher leaving the organisation, and it also gets around the horrible mess of having your name plastered all over the application, if you're performing an update on the item. Many a time I had users phone me up and ask why I made a change to an item at 3am in the morning, when actually it was a workflow running under my name.

The other consideration is also the overhead of item level permissions.Large  lists with item level permissions can cause a great deal of system overhead, making things like load times and reporting very slow, and also, as we've discovered, migration can be very tricky.

Good post as always Cassy Freeman​ -

I try to avoid stripping permissions as it generally leads to confusion with users as they assume they have/require it.

There is one process that we do remove permissions only because it is a regulated process and requires that only the user that it is currently assigned to has access to it.

You're lucky to be in an organisation that only has 1 regulated process in SharePoint.

When I say regulated, I mean that the end result (the documentation) is regulated and we must be able to track the life of the document (who touched it, when, etc.).

I do not mind so much as it is very clear instructions on what is required; not much room for extraneous actions and steps.

Well, that pretty much answers my question. "Again, if the account that the web service is using becomes locked out or deleted then the workflow will fail."

We use Set Item Permissions and find that when a user is no longer a valid employee in the Active Directory, the workflow fails. We were wondering if a Call Web Service action may have a way of circumventing that, but it appears not.

We are developing another workflow to automate the site deletion process. Part of that process is to email the site owners group and ask if they are still using the site. If the person is no longer a valid employee in the Active Directory, the workflow fails. To get around that, we validate each person in the owner's group using the Query User Profile to get their Distinguished Name and then go from there.

What happens if you use the Call Web Service action to manage permissions and have error handling enabled?

Will have a look at this later this week and report back.

in the meantime did you see ‌ comment on the ‌ about valid sharepoint Users? May help you?

Hey Cassy

I've being looking at ways to fix issue with workflow not having the permission to update a list. I've tried set item permissions but that didn't seem to work, what I tried do was select the list name, instead of current item and set the permission to have edit but still ran into permissions issue when workflow tried updating that list. I know Run as workflow owner works as done this in past just wondering is another way we can do this.

Basically what my workflow currently does is an 2 state approval workflow and what I want to do is for it to update a column in another list. For that list however the initiator will only have  read permissions as I do not want them to be updating any fields but I want the workflow to be able to update the field without giving the users edit permission to that other list. Is this possible? The run as administrator does work but just exploring more options if any.

Regards

John

You could perhaps use a web service call to update the item and pass in an account to do that with using managed constant credentials?  I would say for your requirement elevating permissions with the action set is the easiest route.

Hi, Cassy.

I took a look at Paul's comment and much to my delight saw that it was what I had figured out on my own! We get the site owner's distinguished name, we enable error handling when we query the LDAP to pull the useAccountControl, and evaluate whether that is code 512 (active) or 514 (inactive).

Hi, Cassy.

I have been trying to figure out how to use a Call Web Service with error handling enabled to set permissions. The common issue we have is that the person who created the item no longer works with the company, but the item they created is still in an approval or other workflow. We need to secure the item so that only an approver permission group and the Created By have access to it. I tried using AddPermission and using Created By in the permissionIdentifier (string) field, but it doesn't like it. When I manually input a User ID, it works. When an employee is no longer active, they do not have a User ID. Is there a way to make this work or do you think it's just not going to happen?

Using the Created By field is convenient, but not necessarily a "best practice".

Can we do this automatically? That is to change " Who can view the membership of the group?" to "Everyone" in Call Web service when creating this group in nintex. By default it is set to group members.

I can't find a comparable action in O365 workflowcreator. I know some actions got renamed, can you tell me if this one is included and if so, what it is called now?

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings