Operators, triggers and coded values
This reference helps you choose the right comparison operator and action trigger in Builder. Use the visible Builder labels where possible; the coded values are included only to help when reading an existing configuration, integration or Liquid expression.
Choose an operator by the data type
Use an operator that matches the value you are comparing. A condition can look correct but never pass if, for example, it uses a text comparison for a choice item or a numeric comparison for a date.
| What you need to test | Builder operator | When to use it |
|---|---|---|
| Exact text match | Text equals | codes and controlled text values |
| Text differs | Text does not equal | a known text value must not be present |
| Case does not matter | Text equals, ignore case | identifiers where letter case has no meaning |
| Part of a text value | Text contains, starts with or ends with | deliberate search or routing rules; test carefully |
| Pattern match | Text matches regular expression | advanced, reviewed validation or matching only |
| Approximate text | Fuzzy text match | controlled search experiences, not critical identity decisions |
| Number comparison | equals, greater than, less than and variants | quantities, amounts and numeric thresholds |
| Date comparison | equals, after, before and variants | date-only business rules |
| Selected choice | Contains selection item | radio, checkbox or select answers |
| Compare two fields | Same as another field / Different from another field | confirmation values or controlled equality checks |
| Presence | Has a value / Has no value | optional information and route checks |
| Lookup outcome | Lookup found a match / no matches | feed or list search routes |
| Action outcome | Action succeeded / failed | controlled follow-on behaviour |
For a choice comparison, use the stable selection item ID—not the visible label. For date comparisons, use the expected ISO-formatted date and test boundary cases such as today. Some date rules can use the current-day start or end values when the service needs a relative date comparison.
Combine rules with AND or OR
Use all conditions (AND) when every rule needs to pass. Use any condition (OR) when at least one rule is enough. Start by writing the business rule in a sentence, then choose the operator:
flowchart TD
A[Written business rule] --> B{Must every statement be true?}
B -- Yes --> C[Use AND]
B -- No, one is enough --> D[Use OR]
C --> E[Test true and false routes]
D --> EAvoid deeply nested or inverted logic where two small, named conditions would be clearer. Conditions should explain the service rule to a future maintainer.
Choose action timing
An action trigger determines when an action runs in the journey. Select the latest practical trigger that still gives the action the values it needs.
| Trigger | Use it for | Caution |
|---|---|---|
| Page load | data needed as the page begins | returning to the page can run it again |
| After page load | work that follows page setup | confirm all dependencies are available |
| Before validation | controlled preparation before validation | do not expect completed page input |
| After validation | work based on valid submitted answers | common choice for integrations and messages |
| On service completion | final hand-off or confirmation work | test the final completion route |
| Workflow | a workflow step rather than a user page | make the operator outcome clear |
| When a PDF is requested | work required only for that request | avoid using it for unrelated lifecycle work |
Redirects should be last in a trigger sequence. Navigation can prevent later actions from running.
Read coded values safely
Coded values are the stored forms behind Builder labels. They are case-sensitive in configuration and should not be guessed or edited casually. When maintaining an existing service, use the Builder UI to make changes and keep stable IDs intact unless you have reviewed every dependency.
Common coded values include:
- choice comparisons that use the selection item’s stable ID;
- action triggers such as
pageLoad,pagePostValidateandisUserComplete; - result modes such as single or multiple results;
- redirect targets such as internal, external and reload; and
- action IDs and condition IDs used by templates and later actions.
If an unfamiliar coded value appears in a configuration export, locate its Builder setting and detailed reference before changing it. Treat configuration IDs as dependencies, not as cosmetic labels.
Troubleshoot a condition or action
If a condition never passes, check the source value, data type, operator, right-hand value and AND/OR logic. If an action does not run, check its trigger, execution conditions, button filter and whether a preceding redirect changed the route.
Use Builder flow simulation to explore a possible path, then confirm it in User view and QA. Simulation supports design; it is not evidence of live runtime behaviour.