In O365 I have a list where an employee submits a request and once that request is submitted they should not be able to modify or delete the request. In order to achieve this goal the first thing I would like to do is to remove all existing permissions on the list item then add back in the necessary permissions. I have configured the following:
Step 1 - Remove all existing permissions and assign full control to a user group.
Step 2 - Assign read to the user that submitted the request so they can monitor the status.
Step 3 - Assign additional read permissions to people that need to audit the list.
I have used the O365 update permission action to configure these. When I add an item to the list as someone in the user group that is granted full control permissions step 2 and 3 work as expected. But when a user that is not part of the full control group adds an item to the list the workflow goes into a Suspended state between steps 1 and 2. This indicates to me that there is some permission issue.
- What account do workflows run under?
- If the workflow runs under the user account of the person that starts the workflow then how can privileges be escalated?
- How can a workflow be set to always run under a designated service account?
- Or, how can configure the permission steps so that the workflow continues to run?
Solved! Go to Solution.
You need to use AppStep action to make the workflow run under a higher service account like the user who publish that workflow.
Thank you for your reply.
I have added an App Step and placed steps #2 and #3 from the original post inside of the App Step. But, I am receiving the same behavior. If the account that published the workflow starts it then the permissions are set correctly. But if a regular user starts the workflow then it becomes suspended at Step #2.
Any assistance would be appreciated,
I have also granted the Nintex Workflow App and the SharePoint Workflow App full control permissions on the site and the App Step is not correctly applying permissions unless the workflow is started with an admin account.
Yes I had this issue and it took me while playing to workout.
Just put all permission changes in the App Step, and also do step 2 before step 1. Step 1 is removing the users permission from the item all together and can cause issues even within an App Step.
Nintex Support seem to think this should work without the App Step as the service account i'm using to set permissions is SC admin but It keep for normal users which sounds like your above statement.
I was able to come up with a workaround - Instead of removing all permissions to the item then re-adding them - In the "Permission" drop down I used the Remove option to remove the necessary groups. This was done in an App Step though I do not know if that was necessary.