Does constrain on backend workflow (not it’s steps but whole workflow) actually prevent this WF from starting? Or maybe if I setup a call in a specific way it sometimes bypasses this rule, sometimes not?
I heard rumors it doesn’t work, but wanted to confirm this info.
Same question - regarding disabled workflows - are they really disabled or they still can trigger for some reason.
First part - yes it’s this only when. As I am currently having an issue with that that something is triggering the backend workflow and bypassing the criteria, so wondered if anything can make it happen.
Second part of the question is about disable workflow on normal frontend workflows. Should it really stop them as I had a situation a workflow with this box checked could start.
Adding a condition on schedule API workflow will check the condition when the workflow is scheduled. The API workflow will only be scheduled if the condition is met.
Adding a condition on the backend workflow will mean that when the time comes to run the workflow, the condition is checked at that time, and only runs the actions in the workflow if the condition is met.
No… nothing can make that happen… the Only When condition WILL be observed when the Workflow triggers.
That said, there could be any number of things preventing the only when condition from evaluating to what you’re expecting it to… such as incorrect parameter values, privacy rules, or the fact that data may have changed since the workflow was scheduled.
Checking the Disable workflow box WILL stop that workflow from running, no matter what (it’s akin to deleting it completely).
Actually I still have a situation that an element is processes by backend workflow against the condition.
I am still looking what can it be. I even have a terminate workflow step if this condition is met and still I am receiving “effects” of this workflow being triggered. If I learn something I will share this
BTW It would be awesome if bubble can share results of conditions passed by an element.
Additional 2nd step protection (first step is creating a log of the call that initiated the process.
And the log doesn’t give me anything:
, there is no validation info there.
And the order that was processed has the parameter on yes so it shouldn’t be processed.
Unfortunately it’s triggered by another system. So I cannot manually debug it, but maybe I will copy this constrain to a button and try it this way. So this may be the idea. Thou it would be awesome if bubble gave us more info. I also created now a log that displays each of the conditions that the item had so I can later trace what could have gone wrong.
Well what’s funny that actually the correct order is getting invoiced. It wouldn’t be a problem if it would actually not work. As it is worse if it works against the constrains.
–update
The order is the main key to make this flow work - without it it would generate nulls. It is the essence to create anything else in this backend workflow - like invoices, documents etc.
From the pic you posted of the server logs and it looks like there’s no order. Also, it says there’s no user that triggered the action and the action isn’t set to ignore privacy rules. Presumably you’d have privacy rules set up for orders and activity which means they’d be inaccessible without a corresponding user. Yet you’re saying that the “correct” order is being invoiced??
Can you share more about how this is getting triggered and the related workflow actions?