I ran into a similar issue a while back. As the workflow runs with the user permissions removing contribute from the user killed the workflow.
The only solution I could get working was to create a starter workflow. This small starter workflow removed user permissions then started the main workflow using the farm account, at the end of the main workflow we reinstate user permissions.
It's not that elegant but it works and has been running happily for a few months.
Hope this helps.
Commit Pending Changes didn't work either. The error message is "Failed to start workflow. Item does not exist. It may have been deleted by another user."
I'll try this after the holiday when I can get one of our Nintex admins to add this action - I don't have farm account access.
My administrative team is not keen on having to use a Call Web Service and entering the farm account. Is there any other way of doing this? if not, can you provide pros and cons of using this to reassure them it will not cause issues?
The admin team would be responsible for adding the credentials into "Central Admin > Nintex Workflow Management > Manage Workflow Constants" so you would have no visibility of the password or 'real' access to the account. All this would allow you to do is run workflows with elevated permissions.
Your admin team can look at the allowed actions within "Central Admin > Nintex Workflow Management > Manage Allowed Actions" and see the exact actions which could be run with the account. As far as I know there is no access to Central Admin via Nintex/webservices so there is no security issue there.
Additionally, it doesn't need to be the farm account. You could create a new "Workflow User" account and use that as long as the account has edit permissions on the list, perhaps set the account as Site Collection Admin.
Cheers.
Sounds good, Barry, but my administrative team kept trying to come up with other ways to get around the issue so they didn't have to enter the farm account, so I did what I thought I didn't want to do and it is working fine - I combined the two workflows.
The reason I had two workflows was for my convenience. The second workflow was used to copy all of the attachments from an InfoPath form, save them to another library, and then update the InfoPath form. It took me a lot of work and many actions to complete these steps for each attachment (Re: How to move an attachment from infopath form at time of submission using Nintex 2007) - and I had to do this for 23 attachments.. After I perfected this workflow it was easier to add a Start workflow action rather than add everything I built to the original workflow we used for sending out emails and copying data to a list. It was easy, but with the requirements from my team and what we tried with this posting it was time to reconsider and make it one workflow. Thanks to Snippets it couldn't have been easier!
In the second workflow it was as easy as clicking Save, Save as Snippet, adding the name, clicking Submit, going in to my first workflow, selecting the node above the Start workflow action, clicking Insert Action > My snippets > and selecting the appropriate Snippet. The whole workflow appeared, I could remove the Start workflow and everything worked as my users requested.
Barry, you're way is definitely the better way to go when you have to use a Start workflow, but in my case, with my constraints, I'm very thankful for Snippets:)
So, is calling the web service 'StartWorkflowonListItem' the only way to do so using credentials other than those of the person who created or modified the list item? (I'm thinking back to SharePoint Designer (I know, heresy!) which had the 'Impersonation' step which utilized the credentials of the publisher (me) of the workflow to accomplish any action in that step thus making the submitter's permission level in consequential. Doing so helped resolve a lot of permissions issues.)
My scenario: We don't want a submitter to edit an item after they submit it. I initially removed the submitter's (who is also the workflow initiator) permissions completely, which caused initial workflow errors. But, elevating their permissions to just read only as suggested in the workflow err message in the workflow logs by workflow action 'set item permissions' also appears to be causing the workflow to err when it encounters a 'send notification' or 'start (another) workflow' action.