I built a Nintex 2010 workflow in SharePoint 2010 that copies data from a SharePoint Form Library to a SharePoint List and then sets off another workflow to copy InfoPath attachments from the InfoPath form in the SharePoint Form Library to a specified SharePoint library and clear the attachments from the InfoPath form. I had issues with employees reopening the InfoPath form too early and causing the attachment workflow to error. To get around this I am trying to start the workflow with a Set Item Permissions action where I remove all permissions except Full Control for the SharePoint Administrators. I also updated the Set Item Permissions' Common Settings by checking the Run as workflow owner checkbox. Then at the end of the workflow I add all of the permissions back, so users can see and update their forms again.
As the Site Collection Administrator and the one who published the workflow, I would expect the rest of the workflow to work. However, the Start Workflow errors. When I terminate the error occurred and set the workflow off again it works. I tried adding a Pause for 2 minutes after the Set Item Permissions and the Update Item actions in the initial workflow work, but the Start Workflow still errors.
Any help would be greatly appreciated.
Solved! Go to Solution.
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.
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.
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.