Custom rule sets are granular configuration blocks you use to define logic for a single environment.

They usually sit at the bottom of the evaluation hierarchy, allowing feature teams to append or safely override upstream logic enforced by default or *shared rule sets, strictly within the boundary of that specific environment.

Federated management

With custom rule sets, you can scope role-based access permissions directly to specific feature teams. This enables team delegation and safe, federated engineering workflows.

Feature teams can independently manage and test their chunks of business logic without needing access to the full configuration. Once teams commit their custom rule sets to an environment, you control the execution sequence. You can easily rearrange these modular blocks by dragging and dropping them in Delivery Manager, or by defining the order of the modular JSON files through the API.

Workflow and versioning

Custom rule sets support decentralized engineering and operate on a Git-like versioning model:

• Each environment maintains its own independent version history, functioning like an isolated feature branch. Teams can deploy, test, and discard complex logic on-demand without risking accidental changes to parallel environments.
• Iterations made in development environments don't pollute the version history of your production configurations.
• Moving rules from development to staging or production requires an explicit merge action. This ensures all deployments to higher environments are intentional and controlled.

Common use cases

Use custom rule sets to:

• Delegate configuration ownership safely across multiple feature teams.
• Rapidly prototype and test new configuration behaviors.
• Apply environment-specific logic that doesn't need to be shared globally. For example, route test traffic to a staging origin, or perform A/B testing.
• Build simple, one-off configurations that don't require modularity.

📘

Custom rule sets are strictly bound to the environment where they are created and can't be applied to other environments, even within the same workspace. To reuse custom logic across multiple environments or workspaces, you can upgrade the custom rule set to a *shared rule set.