I have a Nintex workflow running on O365 list that was working for months and all of a sudden, it stopped working today and errors out with access is denied. Worked with the site owners to confirm that permissions has not be altered and verified the permissions myself.
Background Information - The site is opened up to everyone with Read access, however, the list and Workflow Tasks list have broken inheritance where the security group that contains every users in the organization is added with Contribute access.
Troubleshooting steps -
In order to get the workflow to work, I temporary elevated every users' access as contributor or added the security group to the Members SharePoint Group which I don't think would be necessary. I have worked with the on-prem version of Nintex Workflow and it has always worked with list that had unique permissions.
Has anyone recently encountered a similar issue? Any suggestions or feedback would be greatly appreciated.
Solved! Go to Solution.
Can you check if the users have write permission to the workflow history list? It's possible the workflow is trying to log information there.
Thank you for your suggestion. I have already tried this as well. Located the Nintex Workflow History broke the inheritance and elevate permissions to no avail.
If you can share the full error that appears on the workflow history page, (click the small blue i ), If it is hitting access denied against a list or other resource in your site it should be shown in the request.
Your suggestion worked. Thank you. I initially went to the Nintex Workflow History list to elevate permissions which didn't work, then I tried the SharePoint Workflow History and that fixed it.
I am not sure if I should be altering permissions to workflow history list. Do you know if there is going to be a permanent fix for this so I don't have to break permissions inheritance?
The requirement of the workflow is that user's can write to the history list - the reason being that a normal workflow that starts will run with the privileges of the user who initiates the workflow. Log to History and other writing to the history log operates as a create list item, so without that permission it is not possible. This would also be true for SharePoint Designer 2013 workflows.
I have exactly the same problem that has just started. Failures started on 29/11 Australian time. Still trying to work through and understand the issue.
If you have changed the permissions on the history list, if you resume a workflow that suspended, does it now log a message to history? If so, is it an expected message?
Where about in the workflow does this occur also, a random point, or the beginning?
It occurs at the very beginning of a workflow. I added a log to history action and republished and that was not happening.
So yes, I have updated the permissions on the 2 lists mentioned above. And it does look I can resume those workflows.
However, while everything you've said about permission on the history lists makes sense, something has definitely changed in the past 2 days. My workflow has been in action for about 8 months up until now, and I can be sure there have been no permission changes at play.