Multi-set rule configuration example

This example publishes three rule sets: base earning, a promotional fallback pair, and purchase tracking. Every set with a matching ACTIVE rule runs.

Final run order

Set	Rules	Behavior
Base earning	Base purchase points	Credits the purchase amount.
Summer promotions	Premium bonus, then standard bonus	A premium match stops only the standard fallback in this set.
Purchase tracking	Increment purchase count, then tag tenth purchase	Keeps state changes separate from earning logic.

A premium purchase receives base earning plus the premium promotional credit. The premium rule has a per-rule budget. Budget exhaustion skips that rule and lets evaluation continue to the fallback and later sets.

Place sets and rules

Insert a new set before an existing one without choosing a numeric order:

{
  "key": "summer-promotions",
  "name": "Summer promotions",
  "position": {
    "placement": "before",
    "reference_id": "71000000-0000-4000-8000-000000000012"
  }
}

Move a rule after another rule. Include the current expected_rule_configuration_version so the request fails if someone has changed the configuration:

{
  "rule_set_id": "71000000-0000-4000-8000-000000000011",
  "position": {
    "placement": "after",
    "reference_id": "71000000-0000-4000-8000-000000000021"
  },
  "expected_rule_configuration_version": 7
}

For a complete configuration draft, put rule_sets and each nested rules array in the order you want them to run.

Keep mutually exclusive rates inside one set

{
  "client_ref": "summer_promotions",
  "key": "summer-promotions",
  "name": "Summer promotions",
  "rules": [
    {
      "client_ref": "premium_bonus",
      "name": "Premium member bonus",
      "condition": "event.type == 'purchase' && event.segment == 'premium'",
      "actions": [
        {
          "type": "CREDIT",
          "asset_id": "71000000-0000-4000-8000-000000000020",
          "amount": "${{ event.amount }}"
        }
      ],
      "budgets": [{"asset_id": "71000000-0000-4000-8000-000000000020", "limit": "10000"}],
      "status": "ACTIVE",
      "stop_after_match": true
    },
    {
      "client_ref": "standard_bonus",
      "name": "Standard summer bonus",
      "condition": "event.type == 'purchase'",
      "actions": [
        {
          "type": "CREDIT",
          "asset_id": "71000000-0000-4000-8000-000000000020",
          "amount": "${{ event.amount * 0.25 }}"
        }
      ],
      "budgets": [],
      "status": "ACTIVE",
      "stop_after_match": false
    }
  ]
}

premium_bonus skips only standard_bonus after a successful match. Base earning and tracking still run in their sets.

Test the snapshot dependency

The tracking set increments purchase_count, then checks whether the participant reached ten purchases:

[
  {
    "client_ref": "increment_purchase_count",
    "name": "Increment purchase count",
    "condition": "event.type == 'purchase'",
    "actions": [{"type": "COUNTER", "key": "purchase_count", "value": "1"}],
    "budgets": [],
    "status": "ACTIVE",
    "stop_after_match": false
  },
  {
    "client_ref": "tag_tenth_purchase",
    "name": "Tag tenth purchase",
    "condition": "event.type == 'purchase' && participant.counter.purchase_count >= 9",
    "actions": [{"type": "TAG", "tag": "TEN_PURCHASES"}],
    "budgets": [],
    "status": "ACTIVE",
    "stop_after_match": false
  }
]

Both conditions read the event-start count. When the count starts at 8, the event ends at 9 and the tag does not apply. When it starts at 9, the tag applies and the event ends at 10. Moving the second rule to a later set would not make it see the same-event increment.

Check event field names

Before applying the draft, compare its event.type, event.amount, and event.segment references with fields seen in recent events. If the draft says event.segmnet, simulation reports a missing field, while the recent events show segment. Fix the field name before publishing. Follow Managing rule configuration to analyze, test, preview, apply, and verify the draft.

Suspend, reactivate, and roll back

A suspended rule stays in its set and keeps its position. Keep its existing id in a complete draft and switch status between SUSPENDED and ACTIVE. Omitting the rule archives it. Rollback restores an earlier configuration as a new revision. Preview the revision you want to restore, review the proposed changes and warnings, then apply it. Past revisions stay unchanged. See Roll back.

Recipes

Integrations

Multi-set rule configuration example

Final run order

Place sets and rules

Keep mutually exclusive rates inside one set

Test the snapshot dependency

Check event field names

Suspend, reactivate, and roll back

​Final run order

​Place sets and rules

​Keep mutually exclusive rates inside one set

​Test the snapshot dependency

​Check event field names

​Suspend, reactivate, and roll back

Final run order

Place sets and rules

Keep mutually exclusive rates inside one set

Test the snapshot dependency

Check event field names

Suspend, reactivate, and roll back