Hey Greg, the first thing I would normally check is that the Workflow Task list that the workflow is associated to is inheriting permissions to the site. Also to the History list on the site

We are also seeing the same issues with workflow's, where the list has broken permission and we have upgraded the visitors read permissions to contribute, and receiving nearly the same error as Greg's team. I have done lots of TS, removed forms, re - created lists, re-created wf, made a list with just a title and a Nintex WF, used our test account and same results. What did work was creating the WF in SP designer, completed without error. Help Nintex!!!!

Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP Unauthorized to GUID information was here

Access denied. You do not have permission to perform this action or access this resource.

Thanks,

Dottie

.

Hey Andrew - The same user will have the workflow run successfully and then the next time they run it it fails. Then the third time they run it it works fine. It's sporadic for each associate, not just sporadic to a limited number of associates.

We are also seeing another error with them stating "Failed to report workflow progress. Could not allocate space for object 'dbo.WorkflowProgress'.'PK_WorkflowProgress' in database 'NW2010DB' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the file"

Thoughts?

Seems to be a disk space problem on your sql server.

Hey Fernando - Thanks for the reply. Wish I had access to that (give me a problem with limited access to the site / server.....), went ahead and forwarded on to our software engineer.

Still looking into main issue though.

We are Office 365, and SP Designer workflow works on the same list, can't be a SQL issue.

Hey Dorothy Verspeek​, the SQL issue was a separate error from the main one. Still trying to figure that one out.

Thanks, I'm like that tend to jump into the pool before there is water in it.

I did submit a support ticket waiting for a response.

Hey Frank Field​ would you be able to assist with this or have someone from Nintex look into the original issue?

Dorothy Verspeek​ please let me know if you hear anything.

Hi Greg,

Please raise a support ticket with Nintex support. Please also quote the Product and Release version number you are using (it looks like you are on-premises from the description in your SQL issue) e.g. NW2013 Release 3.1.8.0. This looks like it is intermittent and so you probably do not have replication steps and this also implies it may be an interaction within your environment. This will be the best way of resolving your issue.

Thanks

Thanks Jon Hardy​ - I went ahead and logged a ticket. We are on-premises with NW2010, version 2.4.1.0

Hey Dorothy Verspeek​ - Have you heard anything more on this? So far the troubleshooting hasn't worked out through the ticket I logged.

-Greg

Nintex is working with me, I'll let you know as soon as they provide good information. So far not resolved.

Hi Team,

I'm also facing this issue. Could you please update if you have received any solution from Nintex team?

We are in urgent need to solve this.

Thanks!

We have the same issue with a customer. Version is on-premise Nintex 2013 (3.2.4.0). Any solutions for this?

Edit:

Maybe this helps. I tried now to deactivate the Incoming Mail Service on my App Server which doesn't serve users anyway and Web Server role is just running for search. I hope this prevents that incoming mails get to the wrong direction as described here:

Lazy approval error with nintex 

Hi Dorothy, Can you share the findings?

Hello Akrasheninnikov,

It has been awhile since this error, but what we have found is that in some cases the History list must have at least contribute permissions for everyone that launches a workflow. Most of the time this does not matter, however we have seen instances where the history list has a log created by Nintex or another source and is using the users validation to update the history list. Providing the user contribute permissions to the history list fixed the issue.

-Dottie