Strategy constraints allow you to set pre-conditions on activation strategies that needs to be satisfied for the activation strategies to take effect. 

Constrain on a specific environment

The most common use case for strategy constraints is that you want an activation strategy to only take effect in a specific environment.  For example you could enable the feature for everyone in development, while you only expose the new feature to a few percentage of the users in production

Demo toggle is enabled for everyone in development and only 10% of the users in production.

Constrain on custom context fields

It is also possible to constrain a activation strategy configuration on custom context fields. A common use case is a multi-tenant service where you want to control roll-out on a tenant identifier. This enable you to decide which customer should get access to your new feature. 

Constrain activation strategy using tenantId

Other custom context fields

We have seen customer use multiple variants of custom context fields to control their feature roll-out:

  • region
  • country
  • customerType
  • tenantId
Combining strategy constraints with the “flexibleRollout” allows you to do gradual roll-out to a specific segment of your user base.