Backend Worklfow only when and disable normal workflow working?

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.

I"m not sure what you mean by ‘constrain on backend workflows’ or ‘disabled workflow’ (there is no option to disable backend workflows)…

But if you’re talking about ‘only when’ conditions on backend workflows then yes… of course they work…

Is that what you’re asking?.. in which case why do you think otherwise?

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.

Yes

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.

1 Like

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).

1 Like

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 :slight_smile:

BTW It would be awesome if bubble can share results of conditions passed by an element. :slight_smile:

Check the logs… it will tell you in there whether the condition have been met or not.

Well unfortunatelly the log doesn’t show me what was passed and what wasn’t
Flow triggering the API:


API Call main:
image
Additional 2nd step protection (first step is creating a log of the call that initiated the process.
image
And the log doesn’t give me anything:
image, there is no validation info there.
And the order that was processed has the parameter on yes so it shouldn’t be processed.

Is that a client-side action?

If so then use the debugger.

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.

It looks like the order parameter isn’t getting passed. That’s why your conditions don’t work.

1 Like

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?

2 Likes

You just killed me with this comment. Thanks! There might be something there.

Given the order is empty here, order’s ManualInvoicing is no will always be true (as an empty yes/no = no), hence the workflow will run.

1 Like