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:
Decision
“Execute this event if the contact does not take action… within a relative time period”
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.
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.
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
I will have a look at your suggestion - I think however, this should maybe be a second thread?
TL;DR Let’s make the entire Decision/Condition hassle much easier and, at the same time, even more powerful!
Rename Decision → Wait for Condition
Rename Condition → Test 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…
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”)
@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”
)