It does make a difference. Donât be fooled into thinking you can update something and then constrain following Actions based on the updated setting. It is bad practice, unpredictable, and completely unreliable. Donât get into the habit of doing that. Separate your Rules if you want to do that sort of thing.
I cannot know for sure what the preceding Actions in your Rule are doing, so I assume they are updating a Deliverer Ticket Tag (or maybe assigning an Entity to the Ticket) and updating a Ticket State (perhaps named DeliveryStatus or the like).
Even so, the Ticket Tag will not have a value until the Ticket is Loaded (which is your first Action). So the message Constraint will always fail, and the message will not be shown. This is because upon entry to the Rule, the Ticket is not Loaded, and the constraint is testing against an empty Ticket Tag value, so it fails and the Message Action is âthrown outâ before it even starts executing anything. In this scenario, this applies to anything that has to do with the Ticket, such as Ticket States, Ticket Tags, and assigned Entities.
So this is effectively how the Show Message Action Constraint is evaluating:
'' == 'Yes'
⊠and because of that the Show Message Action will not execute.
You must split your Rule into 2 Rules.
This is why, in a picture:
Show the Rule where that ^ happens.
Show a screenshot of the Message without the Constraint.
Put something in the message that is guaranteed to be shown, for example:
TktTagTaxInv: -{TICKET TAG:TAX Invoice}-
^^^^^^^^^^^^ ^ ^
even if the tag is empty/blank, those parts will show up.
Without that, the Show Message Action will not appear at all if the Message content is blank/null.
Ultimately, if splitting your Rule into 2 does not work, then something does not match⊠something is set (or not) to some other value than you think it should be. Remember⊠everything is case-sensitive.
I should have mentioned, there are other Print Tag values that are not known until the Ticket is loaded, for example:
{TICKET TOTAL}
⊠or any of these for that matter, so you cannot use them as Action Constraints within the same Rule: