Using rule debugger changes the outcome of rules

You’ll basically define a rule like that.

and an action to trigger that.

I don’t know how it fits to your case but you can execute it after some step you want. That ensures action constraints for the actions inside Execute Auto Tags evals after orders gets tagged.

PS: You don’t need to define an automation command for that. Any command name will work without needing a definition.

1 Like

Thanks @emre

The one problem is that in some of the sequential rules I will need to know what order tag was selected for some additional logic (Pool, AM, PM etc)… But I guess I could store this as a Program Setting
in the first rule (X1) and access it later using {SETTING:} to build the logic.

Am I right in understanding that by using the this chaining method the {SETTING:} would be correctly set by the time to second set of rules is evaluated?

M

2 Likes

Execute Automation Command action passes rule parameters to the next rule. So when you execute it from “Order Tagged” rule you can still access previous rule parameters. For example [:OrderTagValue] parameter will work in “Automation Command Executed” rule as it works in “Order Tagged” rule. So you don’t need a setting to carry rule parameter values to the next rule.

I hope it helps.

1 Like

Wow… That’s really helpful… Amazing that is already built in… So clever! :innocent:

2 Likes

Inside Rule Debugger you can see all available values at the time action executes.

For example you can read ParentPrice value with [:ParentPrice] tag.

fyi: If a Ticket value is set that means you can execute Ticket related printing tags to read ticket values. Or if an Order is set you can execute Order related tags

3 Likes

Really good info to know. Thanks so much!

2 Likes