Rule Execution Order

Configurator Rules are blocks of Snap code you can add to your configurator, giving it considerable logic and flexibility.  Think of them as miniature programs which run at just the right moment to perform the right task.  These rules are triggered by three types of situations, so your logic can run exactly when it's needed.

  1. Events
    Changes in the environment, such as when the configurator has completed loading, the user rotated their phone to change the screen size, or a message has been received from a 3D scene alongside the configurator. 
  2. Rules
    Changes in a field's value, such as when the user selects a new value for a number field, or clears a value from a text field so it's empty. Rules store the bulk of your configurator logic.
  3. Actions
    A click on a button. Your user is explicitly asking for this logic to run.

 


1. Events: Changes in the Environment

When a change in the configurator environment occurs, only the rule associated with that event will be executed.  Environment changes include:

Event Logic Applied
After an existing configured product is created or a new configurator is loaded in the browser's memory, and before the browser draws the configurator UI on-screen.

Three blocks of logic run in this order:

  1. Resize Rues run
  2. Value Rules run
  3. Loaded Rules run
  4. Value Rules run a second time

The two value rules which frame the loaded rule help information flow up and down any nested configurator relationships.

After the user changes a field value. The rule cycle is run (see next section).
After the user interacts with the configurator UI on-screen, not changing a field value.

One block of logic is run, specific to the type of interaction:

Note that if a "setField" Snap block is included in any of these rules, then a field's value has changed. Therefore, the rule cycle described below is also run.

Just after the user submits their configured product for processing by clicking the submit button, and it disappears from the browser:
  1. Submit Rule run
  2. Pricing Rule run
  3. Naming Rule run

(Pricing rules and naming rules are run server-side, not locally. Therefore, they usually complete after the submit rule. If you have Snap code you wish to execute only after the pricing rule completes, consider a general workflow state to contain this code.)

 

2. Rules: Changes in a Field's Value

When the value of a field changes, either from a user changing its value in the UI or from a Snap rule changing the value logically, then all rules listed below will be executed in this specific order. This process is called the "rule cycle".

  1. Field Rule
    • Just the one field rule for the field changed by the user. Other field rules, associated with other fields that were not edited, are not run.
    • When a configurator is first loaded, no field is considered "changed" by the user, so Field rules are not part of the loading process.
  2. Option Filter selections are recalculated.
    • If the current value in any field using this option filter is no longer included in the updated list of selections, then it is replaced with the first available selection in that list.
  3. Value Rules
  4. Validation Rules
  5. Visibility Rules
  6. Pricing Rules
    • Unlike other configurator rules, pricing rules are asynchronous and non-blocking. The next step in the rule cycle starts immediately, while this rule may still be running.
  7. Scene Rules (if a 3D Scene is associated with this configurator). Scene rules are also non-blocking: the configurator is available for the user to edit while the scene updates.

While the order of execution of rules is clearly defined above, you have flexibility within that structure.  If you have multiple rules of the same type, you can re-order them by simply dragging them up or down in the design tree.  You can also rename your rules as your application grows, or cut and paste snap blocks from one rule to another.  This allows you as a designer to organize your rules in a way that makes sense, and to change that organization over time as your configurator grows.

Order of operation is not the order of display.
In any configurator, the order of rule types displayed in the design tree is the order in which you added rules to that configurator.  That order is for display only. It can vary from one configurator to the next. The execution order is always the order in the numbered list above.

Some rules not included in rule cycle.
Notice that some rule types do not appear in either of the lists above.

  • Both Global Rules and Global Event Rules are libraries that define functions, subroutines, and types which can be referenced by other rules in the configurator. 
  • Naming Rule allows a configurator to change the name and description of its configured product based on Snap logic.

Elsewhere in the configurator design tree, you can also add logic for document automation through Output Rules. These are run after the user submits their configuration and are performed on the server.

3. Actions and Buttons: Logic Started by a User

When a user clicks an action or button, the Snap code within it runs. If that code changes the value of a field, then when the code is done the field update automatically triggers the rule cycle described above. Some examples include:

  1. A button labeled "Exploded View" which, when clicked, animates objects in the scene.  Since no field values are edited, the rule cycle does not run.
  2. A button labeled "Apply Deluxe Package" which, when clicked, sets the values of various fields in the configurator to match a certain configuration.  Since one or more fields were edited by this button, the rule cycle is triggered. 

Buttons vs. Actions: what's the difference?

Actions and Buttons are functionally the same. They both run code when a user clicks them. We suggest you use buttons over actions when you design your configurator. They offer more styling options and are easier to move around as your UI design changes in the future.

  • Actions can only appear in the action bar, which is found only in some configurator layouts.
  • Buttons, however, can appear just about anywhere in any UI.

 

Rule execution with nested configurators

When there are nested configurators, the order of execution depends on the situation at hand, and can be quite complex.  Epicor CPQ analyzes the Snap rules to determine which rules need to be run depending on what has changed.  The following steps gives a simple view of how Epicor CPQ makes these decisions.

Nested Rule Cycle

  1. Run value rule of configurator whose field has changed (the "parent" configurator).
  2. If this parent configurator has nested configurators ("children"), and the value rule has changed a field in one of those children, then run a full rule cycle on the nested configurator(s) that were edited.
  3. If #2 was run, and a value rule in the parent references any fields in the child that were changed, then run the value rule in the parent a second time.
  4. Run validation rule of the parent.
  5. Run visibility rule of the parent.
  6. If the parent of this configurator (the "grandparent" configurator) has a value rule that references a field in this configurator, then run a rule cycle on the grandparent.


Was this article helpful?