I have a list workflow that is set to run on the creation of a new item. I have seen a few items created in that list recently where that workflow never ran. It works most of the time, but occasionally, it just doesn't start at all. In the workflow history for those items, there is no record of an instance of the workflow as running, completed, cancelled, or errored. I am not making much progress with the troubleshooting so far. Anyone have ideas of things I can look at to figure out what is going on?
Thanks in advance!
Solved! Go to Solution.
Hi Cassy! No I don't have a pause action at the beginning... here are the first few actions:
I wasn't sure if I should even be messing around with the actions since it doesn't seem to even try to start, but I could certainly add a pause in there if that might help.
Thanks for the speedy reply!
Some things I have tried today so far are to purge the workflow history list... it was a little over 2000 items. I also purged workflow data. That was a bit over 2000. Not sure if that was a worthwhile or if I am just guessing, but there was some good info in Defensive Workflow Design Part 1 - Workflow History Lists that made me think it wasn't a bad idea.
We're getting closer! I was troubleshooting this with a peer, Ross Kovarik, today and we had a hunch it had something to do with the file attachments. If a file is attached with invalid characters in the filename, the result is that the item is created (the submitter receives an error), and the workflows that were set to run on item create never initiate. Yikes! This one sets the item's permissions.
Here is the error received by the users when they submit using an invalid file name for the attachment(s).
Here is a view showing that the workflow never ran on test2 with the invalid attachment file name (included the characters ' and &), but the item was created in the list successfully.
Is this expected behavior? We're running an older version of Nintex workflow (v 18.104.22.168), so I was hoping this might be a bug that is corrected in a more recent version. If anyone is up for trying it out and letting me know, that would be great!
As a workaround, Ross set the workflow up to write "Yes" to another column if permissions were set successfully. It also runs when items are created AND when items are modified but that column is not "Yes". A site workflow runs on a schedule to check for that indicator, and if it isn't there, it sets the column to "Pending" which will now cause the "set permissions" workflow to fire. So, we at least have a safety net for this one, but overall, the situation isn't ideal.
Brian Gullett and I seem to have found a workaround as this issue relates to this:
And this code allows us to put validation on the form so the problematic situation won't be created:
But, we're still curious if this may be fixed in future releases? (or is it already and we're not aware?)
That was a great find, Ross! I was looking at it as a workflow issue and maybe a forms quirk instead of a forms issue that impacted the workflow. Thanks for your help with this!