Skip to main content

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?!

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!


Observations:

* 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


Reply