Fix broken logic in campaign builder - condition vs. decision

As additional information to this issue: Reopen Bug: Condition is broken - ignoring timeout for negative path (e.g for tags, segment memberships) · Issue #12232 · mautic/mautic · GitHub
I agree with @joeyk, that in the dialogs its described as it is.

The campaign builder view is misleading. Also the overal setup is not logical (from my personal view).

Thats the situation:

I quickly draw a campaign, that checks for a visit of a landing page (decision) and it checks for a certain tag assigned to a user (condition).

Why do I think its important?
Same as the visit, also the tag might be added through some asynchronous action to the contact - e.g. some third party integrated system adding that tag later - or a parallel campaign adding it. The “within” should define the time for both paths to become true.

For both I have a positive and a negative path. The negative path is timed to “within 7 days”.
I’d expect that both - decision and condition - behave the same way. The “within” should define the time for both paths to become true.

The negative path is different for decision and condition:

“Execute this event if the contact does not take action… within a relative time period”

“Execute this event… at a relative time period”

Why its unlogic (from my personal view)

  • Decision has the option of checking within timeframe, but can’t have the option of a delay, once the decision is done.
  • Condition has no option of checking within timeframe, but has the option of a delay, once the decision is done.

My Suggestion

  • Both - condition and decision - should have a time period until when the result will be checked “within”.
  • Both - condition and decision - should have a time delay for the next action to be taken after the decision.

Hope this makes it a bit more clear.

1 Like

Thank you @dirk_s , this is a very important discussion!
I would be curious if it’s a bug, or technically this is the only way it can be coded.
@escopecz, do you have an insight?

That’s the reason why there are Decision events and Condition events.

A Decision event is waiting for an action that the contact should make. It must be time-constraint to say when we stopped waiting and decide that the contact should go to the negative path.

A Condition event is something that we know already. Mautic has the data and decide whether the contact should go the positive or negative path. The need for delayed decision was never a considered use case AFAIK.

1 Like

OK - the use case is for instance a third party integration or parallel campaign. Also the condition could wait until decided to go the negative path. So a third party system could add a tag or switch a segment membership…

Alternatively, could tags and segment memberships be added as additional options in the “decision” node?

I don’t see why not. And I think it would be even better than the solution based on a delay for the use case you described. Because the third party system may have an outage and won’t make the change in time. Then the campaign won’t behave as designed. If instead the campaign would be listening on the tag/segment change then an outage of the third party system wouldn’t cause much trouble.


The thing is, I can’t really estimate how much effort it would be for us to implement and propose as a PR.

Could anyone give a rough (!) bullet list, of what would need to be done?

What I would do is to:

  1. Look at how and where the existing decisions work.

  2. This is how it is added to the available decision list:
    mautic/CampaignSubscriber.php at f2324f60e6c5848989c45496ca9e72a313c4f3aa · mautic/mautic · GitHub This just needs to be copy-pasted and adjusted for for example the segment membership change decision

  3. and here is for example how the current page hit decision is executed:
    mautic/CampaignSubscriber.php at f2324f60e6c5848989c45496ca9e72a313c4f3aa · mautic/mautic · GitHub

  4. Check what event we need to listen for to trigger my planned decision. For example when a segment changes then Mautic dispatches this event
    mautic/LeadEvents.php at f2324f60e6c5848989c45496ca9e72a313c4f3aa · mautic/mautic · GitHub

  5. Now in our subscriber we’d have to listen for that event in step 4 and do similar thing like the page hit decision does in step 3.

  6. One more thing to care about is the form type defined in the decision itself. Example: mautic/CampaignSubscriber.php at f2324f60e6c5848989c45496ca9e72a313c4f3aa · mautic/mautic · GitHub which is a class that defines the decision for where the user would be able to configure the decision. Like the select box with the available segments to choose from.

Let me know if you get stuck.

1 Like

Is it planed, on the Condition negative branch to replace the “within” term by “wait” one? Just like it is for the Actions, as it has 1:1 the same functionality.

@IonutOjicaDe that is what the discussion is about… Currently its more likely, that tags and segment memberships would be added to the “decisions” action, as a "condition "is a snapshot of a situation right now - while the “decision” can be waited for. Maybe “decision” isnt’ the right wording then anymore.

But it needs to be done. So far ist not planned yet.

I would not move the “tag” and “segment” from “condition” to “decisions”.
I find ok that they are under “condition”.
I would find very helpful to add these under “decision” also!

But: the wording for all "condition"s needs to be corrected, from “within” to “wait”, as it has and it will have the same functionality as for the “actions”. And there (by “actions”) we use the “wait” term.
I suppose this could be very quick be corrected by a programmer, or?

At least the initial topic here was about to setup the same behavior for tags and segments as with “decisions (wait if it happens until time x)”. They are currently only available in “conditions (check right now)”. But there are cases, where conditions also need time - as with “decisions”. So we were not talking about moving, but about adding it :wink:

I will have a look at your suggestion - I think however, this should maybe be a second thread?

Let’s make the entire Decision/Condition hassle much easier and, at the same time, even more powerful!

  • Rename DecisionWait for Condition
  • Rename ConditionTest Condition once
  • Add Condition-style things like Contact Tags to Wait for Condition
  • Add Decision-style things like Has visited page to Test Condition once

– Long version:
Honestly, I believe that this is not broken logic but…

  1. First of all it is the same old UI challenge - the two look much to similar, we need to be much more explicit about the difference (“within 7 days” is fine for the Decision - but for Condition it should rather read “7 days after testing the condition”)

  2. @dirk_s’ idea is after all about adding a new feature: “Wait for Condition to come true” (as opposed our existing “Test Condition once”)
    +1 for the idea from my side, since that requirement indeed comes up time and again, and is rather cumbersome to implement (using loops)
    Now… Should that feature be part of “Decision”? Absolutely yes, but it should be renamed because it is no longer merely decisions.

Also, things from “Decision” like “visits a page” could be included in “Test Condition once” - then called “has visited page

(Ping @escopecz @joeyk :slight_smile: )


Hi @ekke wonderful summary! You extracted the core of the idea and improved it.
I will change the title.