Skip to main content

What is a Policy Group?

A Policy Group is the top-level container for a set of related business rules. Think of it like a Git repository — it holds multiple versions of your rules and manages their lifecycle. Each policy group has:
  • A unique name (e.g., tiered-discount, fraud-detection)
  • A priority that determines execution order when multiple groups apply
  • A status that controls whether the group accepts traffic

Group Status

Disabling a group stops its production execution as soon as you save. Callers get 403 (P-009) until you set the group back to ACTIVE. See Disabling a Group for what keeps working.

Disabling a Group

Disable a group when its decisions look wrong and you don’t know why yet. It stops production execution without touching what is deployed, so you can find the cause, fix it, and resume from the same state. In the Console, saving a group as Disabled asks for confirmation first. While it is disabled, a banner on the group page has a Re-enable button.

Disable, Undeploy, or Roll Back?

Don’t disable a group for a planned end, such as a promotion that finishes on a known date. Set the version’s effective date range instead. When the range ends, the group switches to its newest ACTIVE version that is still in effect, or is undeployed if there is none. Composite requests keep working either way. A disabled group rejects every composite request that includes it.

Deleting a Group

A group with a live deployment can’t be deleted (P-020). Undeploy it first, which also ends a running A/B test. A deleted group leaves the group list. It can’t be restored or changed: any change to its settings, versions, or rules, starting or adjusting an A/B test, and publishing or deploying are all rejected with 409 (P-059). To start over, create a new group. A deleted group’s rules also stop blocking fact deletion.

Records of a Deleted Group

You can reuse a deleted group’s name right away. Records can then show two groups with the same name: the one you deleted and the one you created later. Rows from the deleted group carry a Deleted badge in Deployments (history and scheduled deployments), Executions, Impact Simulation, Decision Replay, and the recent lists on the Dashboard. Hover the badge to see when the group was deleted. If you deleted the same name more than once, that time tells the groups apart. To see only a deleted group’s records, open the group filter in Deployments or Executions and pick the group under Deleted groups. Each entry shows when the group was deleted. A deleted group’s decisions can still be replayed. In Decision Replay, open New Replay and pick the group under Deleted groups. Single Decision Replay in an Execution Detail lists the versions of that execution’s group, so it works the same for a deleted group. A deleted group that was never executed, deployed, or replayed is permanently deleted after 30 days, and it leaves the filter then.

Creating a Group

In the Console, navigate to Policies → New Policy Group and fill in:
  • Name: A descriptive, unique identifier
  • Description: What this group of rules does
  • Priority: Lower numbers = evaluated first (1 is highest)

Execution Mode

When several policy groups share an Execution Group, the Execution Mode (activationMode) controls how many of those groups run. It counts groups, not rules — every rule of a winning group fires. When using EXCLUSIVE or MAX_N mode, the Priority Strategy (activationStrategy) ranks the competing groups. HIGHEST_PRIORITY is the only strategy — the group with the lowest priority number wins.
An Execution Group with only one member never competes, so the mode has no effect until a second group joins the same Execution Group.
Execution Mode applies at the group level — controlling competition between groups that share the same Execution Group (activationGroup). For rule-level conflict resolution within a single version, see Mutex Groups.

A/B Testing

Policy groups support A/B testing to compare two versions’ performance with live traffic. To start an A/B test, you need a currently deployed (live) version, a test version from the same policy group (must be ACTIVE/published), and a traffic percentage to route to the test version (1–99%). The remaining traffic continues to the live version. A/B tests produce execution logs for both versions, so you can compare their performance in the History tab. Those are the conditions on the group. There is one more on the request: every execution call has to carry context.trafficKey, or the split never happens and the test version stays at 0%. See Traffic Identity Key.

Next Steps

Policy Versions

Learn how versions work inside a group.

A/B Testing

Set up traffic splitting between versions.