What dictates the order in which a workflow triggers? recently edited an existing workflow and added an additional state, didn't think much of it since it was a simple edit. today a user brought up that a field wasn't populating like it normally does on his saved search, narrowed it down to it being cause by the edit on the workflow i did. It relies on checking a value from another workflow, previously this recently edited workflow was running after the other one, now after I made the recent edits this workflow is running first which is causing the value I am checking against to be false since the other workflow hasn't ran yet. any way of changing what orders workflows run in? Or how to know what order they are supposed to run in?

That’s a good question I’ve never thought of this. Can you combine the two into 1 WF or use the initiate wf action to initiate one right after the other in the correct sequence?

Can you go to the History Tab on the Workflow page and see what other changes were made on the WF?

I tried doing the initiate workflow but that wasn't triggering as expected. It seems like the initiate workflow might run on after submit but the workflow that i was initiating only runs on before submit. I ended up having to update the workflows that the second workflow relied on since that was the only way to get it working properly again. Their was no other changes other than adding a state, and adding a few set field value on the new state. Didn't think much of it when I made the edit since it shouldn't have affected anything other than the new set field values. Wasn't expecting it to change the workflow priority and screw up the whole workflow.

Interesting. Sounds like you’ve got some pretty cool workflows going

does it (gasp) order them based on

last modified date

?

It seems like it. Which is kind of an interesting concept. Not sure why that would be the criteria. But at least good to know

Doesn't seem to be based off last modified either, I edited and saved the one that I wanted to run first but that didn't fix it either. @AI1 the use case is we have separate workflows for a handful of large customers since their is different business logic based off multiple factors such as how the order was received, what type of order is it (LTL/Parcel), etc. So instead of having one large workflow that would be hard to follow it's split up into a few different ones with no overlap between them since it's filtered at the workflow level not at the workflow state. The common dependency is geared around approval, if the order is auto approved based on the various business logic from the initial workflows then that is where the second workflow kicks in to set some fields that are used by the warehouse.