I have a stumper for everyone. I have a workflow that I created that has Start when items are modified: Conditional - with some conditional terms. Due to an issue when my infrastructure, I need to change this to Start when items are modified: No. I go to workflow settings, and change the drop down from conditional to no, save the settings, save the workflow, then publish the workflow. Now, if I go back to the workflow and edit the workflow settings, Start when items are modified is somehow, magically, back to 'conditional'. I feel like I'm taking crazy pills, why in the world would this happen?!
Solved! Go to Solution.
that is bizarre behaviour. I would suggest you export and import the workflow and before you publish change the starting behaviour. then remove all new instances of the old workflow?
FWIW, if I start from scratch and give the workflow a new name it correctly saves with the start when modified No. Clearly cache is at play here - where would that type of cache be stored?
To add the the ridiculousness- after i renamed my workflow and updating the calling workflow to talk to the newly named flow - my calling workflow now calls BOTH the newly named workflow and old workflow. What a horrid cache.
I have the same issue. Creating brand new workflow with same name doesn't help. I found that the issue is list specific. Workflow with same name in different library works just fine.
To fix it, i had to get support to delete the conditional event listener. I'm not sure how exactly he did that - but hopefully what he did is helpful to others!
* Nintex creates 4 event receivers in the list
* For some reason other Microsoft event receivers are registered in the list with class: Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver
* Deleting only Nintex event receivers doesn't help
* Deleting all event receivers resolves the issue