Logic Rules
Brief Overview
Logic Rules allow you to create logic statements inside of the Rule Engine based on dynamic text attributes and predefined constants. This allows you to compare fields including dates, numbers, and monetary values by using arithmetic expressions.
Learn more about the Rule Engine.
Use Cases
- Date comparison
- Monetary value comparison
Here are some in depth examples of the way you might use Logic Rules in a solution:
Trigger a ShoutOut close to a due date
You can use a Logic Rule to trigger a ShoutOut in the final days before a due date, to remind users that the deadline is coming up and encourage a final effort.
To do so:
- Create an attribute called DueDate
- Create the following Logic Rule - @DueDate - today <= 5days
Check if the commit value is equal to the total opportunity value
You can use a Logic Rule to easily compare numbers and see if the commit value is equal to the total opportunity value.
- Create dynamic text attributes for both fields - Commit & Total Opportunity
- Create the following Logic Rule - @Commit != @TotalOpportunity
How to use a Logic Rule
- In the Rule Engine, select Logic Rule from the dropdown list
- Enter your logic statement in the highlighted field
How to Create a Logic Statement
A Logic Rule should be written in the form of an equation/in-equation, for example:
- @Date1 - Today < 10Days
- @Attribute1 + @Attribute2 == @Attribute3
While creating the logic rule, a preview bar will display the values in the dynamic fields as long as they appear on the webpage that is connected to the Editor at that time.
Using Dynamic Text Attributes
- To add an attribute, simply type @ and choose an attribute from the dropdown list.
- You can begin typing the attribute name to filter the list.
- You can add as many attributes as you want.
- It is also possible to create new and manage existing attributes directly from the Rule Engine when using the Logic Rule.
Using Dynamic Text Attributes with Static Text Values
Attributes with static text values can be created and used for the comparisons in logic rules.
Example:
@dateTest is the on screen element with a date and @absoluteDate is the static date value.
The builder can now compare the dynamic date on the screen with a predefined date of their choosing.
Using a Predefined Constant
Simply type one of the following constants:
| Constant | Remarks |
| second | Can also use "seconds" |
| minute | Can also use "minutes" |
| hour | Can also use "hours" |
| day | Can also use "days" |
| year | Can also use "years" |
| today | Returns today's dynamic date, for example - 30/07/2020 |
| now | Returns today's dynamic date & time, for example - 30/07/2020 18:30:45 |
Using Arithmetic Actions, and Comparison
You can use arithmetic actions to add, subtract, divide or multiply attributes. For example:
@Att1/12
@Att2*Att3
@Att4+@Att5
@Date1-today
To compare sides of the equation, use one of the following symbols:
| Symbol | Meaning |
| == | Equal |
| != | Not Equal |
| > | Greater than |
| >= | Greater than or equal to |
| < | Less than |
| <= | Less than or equal to |
Troubleshooting
- When using OSE -
- The format of the date in the website should match the builder's local (which implies a date format). If it doesn't, the logic rule might show "invalid date"
- Example: On ynet, an Israeli site, you will see dates in en_IL local (format will be DD/MM/YY - note where the D and the M are). As a builder, I use an attribute based on an on screen element in the logic rule. But, my own browser is set to en_US. If the date was 23/2/22, the logic rule will show "invalid date" as it assumes the local is US which should give a US format (MM/DD/YY). Considering there isn't a 23rd month in the year, the error shows.
- If there isn't a gap between the site's date format and the builder's browser local, all should work well - WM will check the end-user's browser local while running (in published environment), and will "understand" how to read the date
- Example: On screen element holds this date: 3/4/22. Is it March or April? WM "decides" based on the end user's browser local.
- The format of the date in the website should match the builder's local (which implies a date format). If it doesn't, the logic rule might show "invalid date"
- Using fixed/absolute date (text type attribute) -
- WM will save the fixed date as a fixed string. Then. when evaluated (either in the Rule Engine for the builder or in published env for the end user) - WM will read the string according the the user's browser local.
- Example: When writing: 3/4/22, if the builder's browser local is en_US then WM will evaluate the rule in the rule engine as March. But for the end user, it might be evaluated as April if their local is European. This might end up in wrong calculation
- How to Video
- WM will save the fixed date as a fixed string. Then. when evaluated (either in the Rule Engine for the builder or in published env for the end user) - WM will read the string according the the user's browser local.