Split into several cases

By default, a Rule has one bundle of actions that runs whenever its trigger fires and its conditions pass. Splitting into several cases turns that single bundle into a list of mutually-exclusive branches, each with its own condition and its own stack of actions. Use it when the right reward depends on who the member is or how the trigger event looked — not just whether it happened.

What a case is

On step 3 of the Rule wizard, the default layout is a single action block: pick an action, configure it, optionally add more actions below it, and they all run together when the Rule fires. Toggling Split into several cases replaces that single block with a stack of case blocks, each shaped like this:

• A Condition row at the top of the case (same three-slot field / operator / value anatomy as step 2 — see the Conditions reference).
• One or more actions, stacked inside the case the same way actions stack in a non-split Rule.
• A Delay control per action, as in any action.

Only the actions inside the first matching case run. Cases are evaluated top-to-bottom against the triggering event — the first case whose condition passes is the one that fires, and the remaining cases are skipped.

When to use cases

Three patterns cover most of the real-world use:

OR logic. Step 2 conditions combine with AND — every condition must pass. If the logic you want is "fire when X OR Y", split the Rule into two cases, one with X as its condition and one with Y. Both cases can have the same actions if the reward is identical; or they can diverge if X and Y deserve different treatment.

Tiered rewards for one trigger. A single purchase Rule that should give 15 % back to VIPs, 10 % back to regulars, and 5 % back to everyone else is three cases: Tag = VIP → Add credits 15 %, Tag = regular → Add credits 10 %, and a catch-all case with no condition (or a permissive one) → Add credits 5 %. One Rule, three reward paths, no duplication of the trigger and timing setup.

Member-level filtering for triggers without conditions. Some triggers (Total spend updated, Visit updated) expose no condition fields on step 2 — the event itself is the filter. To narrow them by member attributes (total spend crossed €500, tag applied, consent granted), use a case on step 3 instead. Case conditions reach into member-level attributes — tags, balances, consent flags, activity counters — that step 2 conditions generally don't.

tip

If you catch yourself writing two near-identical Rules that differ only in one condition, collapse them into a single Rule with two cases. You get a single trigger setup, a single timing tile, a single rate cap — and the "which branch fires" logic lives in one place instead of being spread across two Rule records.

Cases vs stacked actions

Cases and stacked actions solve different problems; don't mix them up.

• Stacked actions run all together when the Rule fires. Use them when every action should happen on every firing — "Add credits and send an SMS" is stacked because both are always wanted.
• Cases run one branch at a time — the first matching case's actions run, and the rest are skipped. Use them when the actions depend on a condition the trigger event can't express on its own.

You can stack multiple actions inside a single case — each case is structurally a mini stacked-actions block. So the full model is: the Rule splits into cases; within each case, actions stack.

How case conditions differ from step 2 conditions

Step 2 conditions filter the event — did the purchase exceed €20, was it at the Downtown branch, was the coupon in your named list? Case conditions on step 3 can filter the same event-level fields and additionally reach into member state — who the person is at the moment the trigger fired.

In practice that means case conditions can express things like:

• The member holds (or doesn't hold) a specific tag.
• The member's points or credits balance is above / below a threshold.
• The member's total lifetime spend or visit count crosses a value.
• The member has consented to a specific channel.

The exact field list depends on the trigger; open the Condition dropdown inside a case to see what's currently available. If you find yourself wanting a filter that step 2 won't let you set, try step 3 first — it's usually there.

Building a split Rule

The step 3 workflow for a split Rule is straightforward — but one thing is worth doing before you start clicking: plan your case order up front. Cases are evaluated top-to-bottom and cannot be reordered after creation. If you realise halfway through that case 3 should really have been case 1, you'll have to delete the later cases and rebuild them in the right sequence.

With that caveat out of the way:

1. On step 3, toggle Split into several cases.
2. In the first case, pick a Condition — the rule for when this case should fire — and add one or more actions below it. Put your most specific case first.
3. Click + Add case to add the next case. Repeat, ordering from most specific to most permissive.
4. If you want a catch-all branch for everyone who didn't match the earlier cases, add a final case with no condition (or the most permissive one you can write). Because cases evaluate top-to-bottom, this case only runs when all the earlier conditions failed.
5. Preview on step 4 to confirm the branching does what you expect.

warning

Cases cannot be reordered. Plan the sequence from most specific to most permissive before you start filling in details — getting the order wrong means deleting and rebuilding the cases below the mistake.

Gotchas

4 things that commonly trip people up

• Toggling Split after configuring actions wipes them. If you've already filled in actions on step 3 and then enable Split into several cases (or disable it), the wizard warns you and clears the previous configuration. Decide on the structure before you fill in the details. If you realize mid-way you need cases, finish the current Rule and plan the structure up front on the next one.
• First match wins — order matters, and it's locked. A case with a broad condition placed above a case with a narrow one will swallow the narrow one — the narrow case never gets a chance to fire. Since cases cannot be reordered once created, put the most specific cases at the top and the catch-all at the bottom as you build.
• Cases share the Rule's trigger, timing, rate cap, and audience. A case is a branch on the action side only — it doesn't re-filter the trigger or the timing window. If two branches really need different triggers or different rate caps, they should be two separate Rules, not two cases of one.
• Rate cap applies to the whole Rule, not per case. A Rule capped at "once per member per day" fires at most once regardless of which case matched. If you need independent caps per branch (VIP once per day, regular once per week), split into separate Rules.

Worked example — tiered cashback

Goal: give 15 % back to VIP members, 10 % back to members with the regular tag, and 5 % back to everyone else, all on the same purchase trigger.

• Trigger: Makes a purchase.
• Step 2 conditions: none beyond what the default audience/timing tiles already cover — the member-level split happens in cases.
• Step 3: toggle Split into several cases, then:
  • Case 1 — Condition: Tag = VIP. Action: Add credits, 15 % of spent amount. Remember to add the memberCredit exclusion under Don't accumulate for these payment methods.
  • Case 2 — Condition: Tag = regular. Action: Add credits, 10 % of spent amount. Same memberCredit exclusion.
  • Case 3 — Condition: none (catch-all). Action: Add credits, 5 % of spent amount. Same memberCredit exclusion.

Because cases evaluate top-to-bottom, a member tagged VIP gets 15 %, a non-VIP with the regular tag gets 10 %, and everyone else — untagged, anonymous-if-audience-permits, or tagged with something other than VIP / regular — gets 5 %. One Rule, three reward paths.