When using _advanced strategy constraints_ (any operator that isn't `IN` or `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](#incompatibilities) for more information.
**Strategy constraints** are conditions that must be satisfied for an [activation strategy](../reference/activation-strategies) to be evaluated for a feature flag.
Strategy constraints use fields from the [Unleash Context](../reference/unleash-context) to determine whether a strategy should apply or not.
You can constrain both on [standard context fields](../reference/unleash-context#structure) and on [custom context fields](../reference/unleash-context#custom-context-fields).
Unleash SDKs expect all context values to be strings. If you use an operator that acts on non-string values, such as [numeric operators](#numeric-operators) or [date and time operators](#date-and-time-operators), the SDK will attempt to convert the string into the expected type. If the conversion fails, the constraint will evaluate to `false`.
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](../how-to/how-to-add-strategy-constraints).
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](../how-to/how-to-define-custom-context-fields) for more info.
By using [custom context fields](../reference/unleash-context#custom-context-fields), you can tailor strategy constraints to your specific use case, such as:
You can also combine strategy constraints with the [gradual rollout strategy](../reference/activation-strategies#gradual-rollout) to do a gradual rollout to a **specific segment** of your user base.
| `userId` | `STR_ENDS_WITH` | `@example.com, @mycompany.com` | Evaluates to `true` for users whose user IDs end with `@example.com` or `@mycompany.com`. |
| `currentTime` | `DATE_AFTER` | `2022-06-05 21:43:22Z` | Evaluates to `true` if the current time is after `2022-06-05 21:43:22Z`. |
| `userScore`[^1] | `NUM_GTE` | `1000` | Evaluates to `true` if the [custom context field](../reference/unleash-context#custom-context-fields) `userScore` has a value of `1000` or higher. |
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 supports a wide range of constraint operators. `IN` and `NOT_IN` are basic operators that are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](../reference/sdks#strategy-constraints).
All constraint expressions can be **negated**, meaning that they get their opposite value. Constraints are evaluated to either `true` or `false`. Negating a constraint would turn a `true` value into a `false` and a `false` value into a `true` value.
You can read more about [numeric equality](https://en.wikipedia.org/wiki/Equality_(mathematics) "Mathematical equality at Wikipedia") or [numeric inequality operators at Wikipedia](https://en.wikipedia.org/wiki/Inequality_(mathematics)).
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.
String operators differ from the other categories in two different ways:
- all operators accept multiple values
- most operators also consider [letter case](https://en.wikipedia.org/wiki/Letter_case "letter case on Wikipedia") and can be set to be case-sensitive or case-insensitive
- Optionally, you can also add pre-release version information by adding a hyphen and series of dot separated identifiers after the patch version. Example: `1.2.3-rc.2`
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](https://semver.org/#spec-item-11).
You can read more about SemVer in [the full SemVer specification](https://semver.org/).
| Greater than or equal to | Negate `SEMVER_LT` | **greater than or equal to** the provided value |
| Less than or equal to | Negate `SEMVER_GT` | **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".
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](../reference/unleash-context) to work. All official [Unleash client SDKs](../reference/sdks) support the option to pass [dynamic context values](../reference/unleash-context#structure) to the `isEnabled` function (or the SDK's equivalent).
If the strategy constraint uses a [**standard Unleash Context field**](../reference/unleash-context#structure), set the context field to the value you wish to give it.
If the strategy constraint uses a [**custom context field**](../reference/unleash-context#custom-context-fields), 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 `5`.
This value can still be negated as explained in [the section on negating values](#constraint-negation).
Explore the content in this subsection in more depth in [the topic guide on using Unleash with large constraints](/understanding-unleash/managing-constraints).
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](../reference/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 `membership` is `premium`? And if they're employees, maybe you're better off checking whether their user ID ends with `@yourcompany.tld`?
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 flag 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.
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):
Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks#strategy-constraints).
After Unleash 4.9, we updated the [Unleash client specification](https://github.com/Unleash/client-specification). Going forward, any constraint that a client does not recognize, **must be evaluated as `false`**
Before Unleash 4.3, using strategy constraints was the recommended way to have different flag 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](../reference/environments).
