Before Unleash 4.16, strategy constraints were only available to Unleash Pro and Enterprise users. From 4.16 onwards, they're available to everyone.
Unleash 4.9 introduced a more comprehensive set of constraint operators. These require that both Unleash and your client SDK of choice support them. See the SDK compatibility table for more information. Prior to Unleash 4.9, the only available operators were
When using advanced strategy constraints (any operator that isn't
NOT_IN), make sure your client SDK is up to date and supports this feature. For older versions of the client SDKs we cannot guarantee any specific behavior. Please see the incompatibilities section for more information.
Strategy constraints are conditions that must be satisfied for an activation strategy to be evaluated for a feature toggle. With strategy constraints, you can:
- roll out a feature only to users in a specific region
- schedule a feature to be released at a specific time
- make a feature available for a limited time only
- release a feature to users with one of a set of email addresses
- ... and much more!
Strategy constraints use fields from the Unleash Context to determine whether a strategy should apply or not. You can constrain both on standard context fields and on custom context fields.
This page explains what strategy constraints are in Unleash and how they work. If you want to know how you add strategy constraints to an activation strategy, see the corresponding how-to guide.
Constraining on custom context fields
To be able to constrain on a field, it must be listed under the Context Field menu. If a field isn't listed, you can add it yourself. See the how-to guide for creating your own custom fields for more info.
Unleash only provides a limited set of context fields by default, and they may not fulfill all your needs. By using custom context fields, you can tailor strategy constraints to your specific use case, such as:
- based on tenant IDs, release a feature to only specific tenants in a multi-tenant setup
- release a feature to users in a specific region
- release a feature only to beta testers
You can also combine strategy constraints with the gradual rollout strategy to do a gradual rollout to a specific segment of your user base.
Each strategy constraint has three parts:
- a context field: The context field to use for evaluation.
- an operator: One of the operators listed below.
- a value/list of values: A value or list of values to use in the evaluation of the constraint.
These parts turn the strategy constraint into an expression that evaluates to either
To clarify, here's a few example strategy constraints and what they do:
|Evaluates to |
|Evaluates to |
|Evaluates to |
Strategy constraint operators
In this section,
<context-field> is used as a placeholder for an arbitrary context field. With the exception of the
currentTime field, you can use any context field in its place.
Unleash currently supports 15 different constraint operators. The operators can be grouped into four different categories based on their method of comparison.
Constraint negation / inversion
All constraint expressions can be negated, meaning that they get their opposite value. Constraints are evaluated to either
false. Negating a constraint would turn a
true value into a
false and a
false value into a
For instance, using the numeric equivalence operator
NUM_EQ, the following truth table shows the how value negation affects the result:
Numeric operators compare the numeric values of context fields with your provided value.
Numeric operators only accept single values.
|equal to the provided value; the mathematical |
|strictly greater than the provided value; the mathematical |
|greater than or equal to the provided value; the mathematical |
|strictly less than the provided value; the mathematical |
|less than or equal to the provided value; the mathematical |
You can read more about numeric equality or numeric inequality operators at Wikipedia.
Date and time operators
currentTimeand date and time operators
The date and time operators are only available on the
currentTime context field. Furthermore, the
currentTime context field can not be used with any of the other operators.
With the date and time operators, you can enable a feature before and/or after a specified time.
The operators compare the Unleash context's
currentTime property against the provided value.
You can create a time span by combining the two constraint operators using two different constraints on the same strategy.
In that case the strategy will be evaluated from
DATE_AFTER and until
Date and time operators only support single values.
|after the provided date|
|before the provided date|
String operators differ from the other categories in two different ways:
- all operators accept multiple values
- most operators also consider letter case and can be set to be case-sensitive or case-insensitive
|Name||Supports case-insensitivity||Available since|
|is equal to any of the provided values||No||v3.3|
|is not equal to any of the provided values||No||v3.3|
|contains any of the provided strings||Yes||v4.9|
|ends with any of the provided strings||Yes||v4.9|
|starts with any of the provided strings||Yes||v4.9|
Versioning (SemVer) operators
The SemVer operators are used to compare version numbers such as application versions, dependency versions, etc.
The SemVer input must follow a few rules:
- The value you enter must start with and contain at least major, minor, and patch versions: Example:
- Optionally, you can also add pre-release version information by adding a hyphen and series of dot separated identifiers after the patch version. Example:
Versions with pre-release indicators (e.g.
4.8.0-rc.2) are considered less than versions without (e.g.
4.8.0) in accordance with the SemVer specification, item 11.
You can read more about SemVer in the full SemVer specification.
SemVer operators only support single values.
|equal to the provided value|
|strictly greater than the provided value|
|strictly less than the provided value|
Additionally, you can use negation to get less than or equal to and greater than or equal to functionality:
|Greater than or equal to||Negate ||greater than or equal to the provided value|
|Less than or equal to||Negate ||less than or equal to the provided value|
"Not less than 2.0.0" is the same as "greater than or equal to 2.0.0". The same applies for less than or equal: "Not greater than 1.9.5." is the same as "less than or equal to 1.9.5".
Interacting with strategy constraints in the client SDKs
This section gives a brief overview over to use the client SDKs to interact with strategy constraints. The exact steps will vary depending on which client you are using, so make sure to consult the documentation for your specific client SDK.
Strategy constraints require the Unleash Context to work. All official Unleash client SDKs support the option to pass dynamic context values to the
isEnabled function (or the SDK's equivalent).
If the strategy constraint uses a standard Unleash Context field, set the context field to the value you wish to give it.
If the strategy constraint uses a custom context field, use the Unleash Context's
properties field. Use the name of the custom context field as a key and set the value to your desired string.
If you set a context field to a value that the SDKs cannot parse correctly for a chosen constraint operator, the strategy constraint will evaluate to false.
In other words: if you have a strategy constraint operator that expects a number, such as
NUM_GT, but you set the corresponding context field to a string value, then the expression will be false:
"some string" is not greater than
This value can still be negated as explained in the section on negating values.
Constraint limitations (or "how many user IDs can I add to a constraint")
When using a constraint operator that accepts a list of values, it might be tempting to add a large number of values to that list. However, we advise you not to do that: Unleash is not a database, and is not intended to store large amounts of data. Instead you should try and find a different way to achieve what you want.
For instance, instead of adding hundreds of user ids to the constraint value list, think about what properties those users share. Are they beta testers? Are they premium members? Are they employees?
Can you map their common feature into an Unleash context property instead and set the constraint on that? If they're beta testers, how about using a
betaTester property? And likewise, for premium members, you could check to see if their
premium? And if they're employees, maybe you're better off checking whether their user ID ends with
The reason why you should try and keep value lists small has to do with Unleash's evaluation model: Because Unleash's server-side SDKs fetch the full feature toggle configuration from Unleash, every value that you add to that constraint value list will increase the payload size. For small numbers, this isn't an issue, but as the list grows, so will the payload, and so will the time and processing power used by the SDK to evaluate the feature.
Incompatibilities and undefined behavior
It's important that you use an up-to-date client SDK if you're using the advanced constraint operators introduced in Unleash 4.9. If your client SDK does not support the new operators, we cannot guarantee how it'll react. As a result, you may see different behavior across applications.
If you use the new constraints with old SDKs, here's how it'll affect some of the SDKs (the list is not exhaustive):
- The Node.js and Go client SDKs will ignore the new constraints completely: the constraints will not affect the toggle's status.
- The Python client SDK will evaluate the toggle to false, as it cannot evaluate the constraint successfully.
- The .NET, Ruby, and PHP SDKs raise exceptions if the provided operator is not
Please inspect the SDK compatibility table to see which version of your preferred SDK introduced support for this feature.
After Unleash 4.9, we updated the Unleash client specification. Going forward, any constraint that a client does not recognize, must be evaluated as
[Deprecated]: Constrain on a specific environment
Before Unleash 4.3, using strategy constraints was the recommended way to have different toggle configurations per environment. Now that Unleash has environment support built in, we no longer recommend you use strategy constraints for this. Instead, see the environments documentation.
userScoreis not a default Unleash field, but can be added as a custom context field.↩