Although having full control permission on a site and on a list when user tries to publish a nintex workflow gets an error 401:unauthorized.
Can you try to publish check the workflow in different name (Unchecked overwrite existing version) and see whether you are able to publish without any error message.
If still issue persist, then check any action items which requires your permission to access and try publishing without validation option in the workflow settings.
We are having the same issue.
We have 3 environments and the workflow fails to publish in only one of the environments.
We narrowed down the problem to the "Assign Flexi Task". We create a test workflow with just an "Assign Flexi Task" with hardcoded values inside, and the workflow fails to publish with a 401 Unauthorized error.
We are currently stumped as well and looking for help.
we currently face exactly the same problem. Has yours been solved meanwhile and how?
One of our admin users cannot publish Nintex workflows as soon as they contain an "Assign Flexi Task" action. Once it has been added to a workflow publishing results in an 401 unauthorized error. Even if we then remove the action, the error persists.
An other admin user (me) however can publish the workflow with the "Assign Flexi Task" action.
Could there be any remining difference in the rights of the 2 users, deeply hidden somewhere in Nintex?
Nintex doesn't really have "deep hidden" areas, there are some interesting places though. But besides the databases, the entire solution is based on SharePoint lists and timer jobs. Most issues with permissions are because of site/list permission setup. Others are service related to sharepoint (see Alexey's response below). If the issue is just with the flexi task only, may it has to do with the use of it's content types on the workflow task list. Those content types can be modified when publishing workflows to account for the outcomes. If a user can't modify the list, then it will receive a 401.
That's a good place to start when you see one account working great, but the other can't.
It is possible that the two issues here could be entirely different. Chris, you may want to post a new question on it.
The first thing I would check is the Allowed Workflow Designers. Go to the site settings, under Nintex Workflow section click on Allowed workflow designers. Make sure this list is still inheriting from the parent site permissions.
Chris, make sure that action is still allowed to be used in Managed Allowed Actions
This may be caused by AppFabric Distributed Cache failure. Check your cache servers.
ULS might show something like (this particular one has event id of ah24w)
Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage 'DistributedLogonTokenCache' - Exception 'Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.) ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '10675199.02:48:05.4775807'. ---> System.IO.IOException: The read operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '10675199.02:48:05.4775807'. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
I have also seen an indication of the user being not granted Design permissions to add field to web:
Access Denied. Exception: Attempted to perform an unauthorized operation.,StackTrace:
at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)
at Microsoft.SharePoint.SPSecurableObject.CheckPermissions(SPBasePermissions permissionMask)
at Microsoft.SharePoint.SPFieldCollection.AddFieldToWeb(String strXml, Boolean checkDisplayName, Boolean isMigration, Boolean ignoreExistsError, Guid featureId, Guid solutionId)
at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op, Boolean isMigration, Boolean fResetCTCol)
at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op)
at Nintex.Workflow.Common.NWSharePointObjects.UpgradeWorkflowContentType(SPWeb web)
Retrieving data ...