Home › Forums › Product Configurator › Called From Record Rule Variables
-
AuthorPosts
-
Andreas Koller
May 8, 2026 at 9:19 amPost count: 2Hello all,
I’m reading through the release notes for 4.1 and struggle understanding the improvement “Called from record rule variables”.
- Added variables to the called from record when running rules. For example, if the rule is run from the option choice, you can use a variable to identify its choice code
Can provide an example use case that will help me understand.
Thank you!
Andy Koller-
This topic was modified 5 months ago by
Andreas Koller.
Terri Vaive
May 12, 2026 at 6:52 amPost count: 508::Hello Andreas,
CALLEDFROM is a built-in variable to identify the source that is calling a rule, allowing rules to behave or evaluate differently depending on where they are being called from. The variables available are CALLEDFROM.CHOICE, CALLEDFROM.OPTION, and CALLEDFROM.TABLEID where .CHOICE is the choice code, .OPTION is the option code, and .TABLEID is the table id. As rules are currently only triggered by the Configurator BOM (e.g., the option line in the BOM Designer) or the option choice (i.e., to conditionally hide/show) those are the only two sources.
One application is when you require a rule for the option choices to hide/show them and your criteria is mostly same except it can vary based on the specific choice code. You can use the same rule for multiple option choices and include the CALLEDFROM.CHOICE variable in your definition lines to have it evaluate differently based on the specific option choice calling the rule.
For example, suppose you have two options: LOCATION and OPERATION, and based on the LOCATION only certain OPERATION choices can be selected. If you set up your OPERATION choices so that their codes include an identifier from the LOCATION choice codes (e.g., LOCATION includes choices A and B, and OPERATION includes choices 001A, 002A, 002B, 003B, etc.) you can then set up a rule on the OPERATION option choices to conditionally hide/show them based on what the user selects for the LOCATION choice (e.g., CALLEDFROM.CHOICE is in filter/ is not in filter *[LOCATION.CHOICE]). Depending how you structure the rule, if LOCATION is set to A it could hide 002B and 003C resulting in just 001A and 002B available to select for OPERATION, or if LOCATION is B it could hide 001A and 002A. If the condition is set up like CALLEDFROM.CHOICE is in filter/ is not in filter *[LOCATION.CHOICE] it would evaluate to ‘001A is in filter/ is not in filter *A’, ‘002A is in filter/ is not in filter *A’, ‘002B is in filter/ is not in filter *A’, ‘003B is in filter/ is not in filter *A’.
Thank you,
Andreas Koller
May 15, 2026 at 5:13 amPost count: 2::Hi Terri,
this has been very helpful, thank you for the example, I was able to recreate.
Will you also please weigh in on the following to further solidify my understanding:
- Since Rules on Option Choices do not run Action Definitions other than Run Rule, I draw the conclusion that it is not best practice to take a Rule ID tied to an Option and use it on Option Choices?
- If subsequent Options and Option Choices are dependent on a combination of Options, would you recommend writing one Rule and to set the Rule Definition ID to the value of the Rule just written for all Options that dictate the outcome? For now, we’ve followed an informal 1:1 between Configurator Option and Rule Definition Header but I have concerns about the resulting added complexity and needed relationship between Rules.
Thank you!
Andy Koller
Terri Vaive
May 20, 2026 at 11:16 amPost count: 508::Hello Andreas,
- Correct, generally you would not assign an existing Option rule as an Option Choice rule. Technically it is possible, and depending how the rule is set up it could work.
- In the current design, it expects a one-to-one relationship for rules assigned to Options. The Run Rule action allows one Option to trigger the rules assigned to another Option.
Thank you,
-
AuthorPosts
- You must be logged in to reply to this topic.