chore: rename toggle to flags in docs #3 (#7143)

website/docs/reference/activation-strategies.md

@@ -8,7 +8,7 @@ Unleash comes with a number of built-in strategies (described below) that can be
 
 All [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) and the [Unleash Proxy](../generated/unleash-proxy.md) implement the default strategies (and allow you to add your own [custom strategy implementations](../reference/custom-activation-strategies.md#implementation)). The [front-end client SDKs](../reference/sdks/index.md#front-end-sdks) do not do the evaluation themselves, instead relying on the [Unleash Proxy](../generated/unleash-proxy.md) to take care of the implementation and evaluation.
 
-Some activation strategies require the client to provide the current [Unleash context](unleash-context.md) to the toggle evaluation function for the evaluation to be done correctly.
+Some activation strategies require the client to provide the current [Unleash context](unleash-context.md) to the flag evaluation function for the evaluation to be done correctly.
 
 The following activation strategies are bundled with Unleash and always available:
 
@@ -32,7 +32,7 @@ Active for users with a `userId` defined in the `userIds` list. A typical use ca
 
 **Parameters**
 
-- userIds - _List of user IDs you want the feature toggle to be enabled for_
+- userIds - _List of user IDs you want the feature flag to be enabled for_
 
 This strategy has the following modelling name in the code:
 
@@ -49,8 +49,8 @@ A flexible rollout strategy which combines all gradual rollout strategies in to
   - **userId** - guaranteed to be sticky on userId. If userId not present the behavior would be false
   - **sessionId** - guaranteed to be sticky on sessionId. If sessionId not present the behavior would be false.
   - **random** - no stickiness guaranteed. For every isEnabled call it will yield a random true/false based on the selected rollout percentage.
-- **groupId** is used to ensure that different toggles will **hash differently** for the same user. The groupId defaults to _feature toggle name_, but the user can override it to _correlate rollout_ of multiple feature toggles.
+- **groupId** is used to ensure that different flags will **hash differently** for the same user. The groupId defaults to _feature flag name_, but the user can override it to _correlate rollout_ of multiple feature flags.
-- **rollout** The percentage (0-100) you want to enable the feature toggle for.
+- **rollout** The percentage (0-100) you want to enable the feature flag for.
 
 This strategy has the following modelling name in the code:
 
@@ -68,7 +68,7 @@ By enabling the stickiness option on a custom context field you can use the cust
 
 ## IPs {#ips}
 
-The remote address strategy activates a feature toggle for remote addresses defined in the IP list. We occasionally use this strategy to enable a feature only for IPs in our office network.
+The remote address strategy activates a feature flag for remote addresses defined in the IP list. We occasionally use this strategy to enable a feature only for IPs in our office network.
 
 **Parameters**
 
@@ -80,11 +80,11 @@ This strategy has the following modelling name in the code:
 
 ## Hostnames {#hostnames}
 
-The application hostname strategy activates a feature toggle for client instances with a hostName in the `hostNames` list.
+The application hostname strategy activates a feature flag for client instances with a hostName in the `hostNames` list.
 
 **Parameters**
 
-- hostNames - _List of hostnames to enable the feature toggle for._
+- hostNames - _List of hostnames to enable the feature flag for._
 
 This strategy has the following modelling name in the code:
 
@@ -92,17 +92,17 @@ This strategy has the following modelling name in the code:
 
 ## Multiple activation strategies {#multiple-activation-strategies}
 
-You can apply as many activation strategies to a toggle as you want. When a toggle has multiple strategies, Unleash will check each strategy in isolation. If any one of the strategies would enable the toggle for the current user, then the toggle is enabled.
+You can apply as many activation strategies to a flag as you want. When a flag has multiple strategies, Unleash will check each strategy in isolation. If any one of the strategies would enable the flag for the current user, then the flag is enabled.
 
 As an example, consider a case where you want to roll a feature out to 75% of your users. However, you also want to make sure that you and your product lead get access to the feature. To achieve this, you would apply a **gradual rollout** strategy and set it to 75%. Additionally, you would add a **user IDs** strategy and add `engineer@mycompany.com` and `productlead@mycompany.com`.
 
-![A feature toggle with two active strategies: a user ID strategy and a gradual rollout strategy. The strategies are configured as described in the preceding paragraph.](/img/control_rollout_multiple_strategies.png)
+![A feature flag with two active strategies: a user ID strategy and a gradual rollout strategy. The strategies are configured as described in the preceding paragraph.](/img/control_rollout_multiple_strategies.png)
 
 ## Deprecated strategies
 
 ### gradualRolloutUserId (DEPRECATED from v4) - Use Gradual rollout instead {#gradualrolloutuserid-deprecated-from-v4---use-gradual-rollout-instead}
 
-The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged-in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
+The `gradualRolloutUserId` strategy gradually activates a feature flag for logged-in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
 
 ![hash_and_normalise](/img/hash_and_normalise.png)
 
@@ -110,22 +110,22 @@ Starting from v3.x all clients should use the 32-bit [MurmurHash3](https://en.wi
 
 **Parameters**
 
-- percentage - _The percentage (0-100) you want to enable the feature toggle for._
+- percentage - _The percentage (0-100) you want to enable the feature flag for._
-- groupId - _Used to define an activation group, which allows you to correlate rollout across feature toggles._
+- groupId - _Used to define an activation group, which allows you to correlate rollout across feature flags._
 
 ### gradualRolloutSessionId (DEPRECATED from v4) - Use Gradual rollout instead {#gradualrolloutsessionid-deprecated-from-v4---use-gradual-rollout-instead}
 
-Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged-in users), guaranteeing that a user will get the same experience within a session.
+Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature flag, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged-in users), guaranteeing that a user will get the same experience within a session.
 
 **Parameters**
 
-- percentage - _The percentage (0-100) you want to enable the feature toggle for._
+- percentage - _The percentage (0-100) you want to enable the feature flag for._
-- groupId - _Used to define an activation group, which allows you to correlate rollout across feature toggles._
+- groupId - _Used to define an activation group, which allows you to correlate rollout across feature flags._
 
 ### gradualRolloutRandom (DEPRECATED from v4) - Use Gradual rollout instead {#gradualrolloutrandom-deprecated-from-v4---use-gradual-rollout-instead}
 
-The `gradualRolloutRandom` strategy randomly activates a feature toggle and has no stickiness. We have found this rollout strategy very useful in some scenarios, especially when we enable a feature which is not visible to the user. It is also the strategy we use to sample metrics and error reports.
+The `gradualRolloutRandom` strategy randomly activates a feature flag and has no stickiness. We have found this rollout strategy very useful in some scenarios, especially when we enable a feature which is not visible to the user. It is also the strategy we use to sample metrics and error reports.
 
 **Parameters**
 
-- percentage - _The percentage (0-100) you want to enable the feature toggle for._
+- percentage - _The percentage (0-100) you want to enable the feature flag for._

website/docs/reference/change-requests.md

@@ -15,13 +15,13 @@ The change requests for segments was introduced in **Unleash 5.4.0**.
 <VideoContent videoUrls={["https://www.youtube.com/embed/ENUqFVcdr-w"]}/>
 
 
-Feature flagging is a powerful tool, and because it's so powerful, you sometimes need to practice caution. The ability to have complete control over your production environment comes at the cost of the potential to make mistakes in production. Change requests were introduced in version 4.19.0 to alleviate this fear. Change requests allow you to group changes together and apply them to production at the same time, instead of applying changes directly to production. This allows you to make multiple changes to feature toggles and their configuration and status (on/off) all at once, reducing the risk of errors in production.
+Feature flagging is a powerful tool, and because it's so powerful, you sometimes need to practice caution. The ability to have complete control over your production environment comes at the cost of the potential to make mistakes in production. Change requests were introduced in version 4.19.0 to alleviate this fear. Change requests allow you to group changes together and apply them to production at the same time, instead of applying changes directly to production. This allows you to make multiple changes to feature flags and their configuration and status (on/off) all at once, reducing the risk of errors in production.
 
 Our goal is developer efficiency, but we also recognize that we have users and customers in highly regulated industries, governed by law and strict requirements. Therefore, we have added a capability to change requests that will allow you to enforce the _4 eyes principle_.
 
 ## Change request configuration
 
-The change request configuration can be set up per project, per environment. This means that you can have different change request configurations for different environments, such as production and development. This is useful because different environments may have different requirements, so you can customize the change request configuration to fit those requirements. However, this also means that you cannot change toggles across projects in the same change request.
+The change request configuration can be set up per project, per environment. This means that you can have different change request configurations for different environments, such as production and development. This is useful because different environments may have different requirements, so you can customize the change request configuration to fit those requirements. However, this also means that you cannot change flags across projects in the same change request.
 
 Currently there are two configuration options for change requests:
 * **Enable change requests** - This is a boolean value that enables or disables change requests for the project and environment.
@@ -34,12 +34,12 @@ The change request configuration can be set up in the project settings page:
 
 ## Change request flow
 
-Once a change request flow is configured for a project and environment, you can no longer directly change the status of a toggle. Instead, you will be asked to put your changes into a draft. The change request flow handles the following scenarios:
+Once a change request flow is configured for a project and environment, you can no longer directly change the status of a flag. Instead, you will be asked to put your changes into a draft. The change request flow handles the following scenarios:
 
-* Updating the status of a toggle in the environment
+* Updating the status of a flag in the environment
-* Adding a strategy to the feature toggle in the environment
+* Adding a strategy to the feature flag in the environment
-* Updating a strategy of a feature toggle in the environment
+* Updating a strategy of a feature flag in the environment
-* Deleting a strategy from a feature toggle in the environment
+* Deleting a strategy from a feature flag in the environment
 
 The flow can be summarized as follows:
 
@@ -51,7 +51,7 @@ Once a change is added to a draft, the draft needs to be completed before anothe
 * **In review** - The change request is in review mode, and can be edited by the user that created the draft. If editing occurs, all current approvals are revoked
 * **Approved** - The change request has been approved by the required number of users.
 * **Scheduled** - The change request has been scheduled and will be applied at the scheduled time (unless there are conflicts, as described in the section on [scheduling change requests](#scheduled-changes)).
-* **Applied** - The change request has been applied to the environment. The feature toggle configuration is updated.
+* **Applied** - The change request has been applied to the environment. The feature flag configuration is updated.
 * **Cancelled** - The change request has been cancelled by the change request author or by an admin.
 * **Rejected** - The change request has been rejected by the reviewer or by an admin.
 
@@ -132,11 +132,11 @@ You can prevent non-project members from submitting change requests by setting a
 
 ### Circumventing change requests
 
-The **skip change requests** permission allows users to bypass the change request flow. Users with this permission can change feature toggles directly (they are of course still limited by any other permissions they have).
+The **skip change requests** permission allows users to bypass the change request flow. Users with this permission can change feature flags directly (they are of course still limited by any other permissions they have).
 
 The skip change requests permission was designed to make it possible to quickly turn something off in the event that a feature release didn't go as expected or was causing issues.
 
-The skip change requests permission does **not** grant any other permissions, so to be allowed to do things as enabling/disabling a toggle, the user will still need the explicit permissions to do that too.
+The skip change requests permission does **not** grant any other permissions, so to be allowed to do things as enabling/disabling a flag, the user will still need the explicit permissions to do that too.
 
 In the UI non-admin users with **skip change requests** permission and explicit permission to perform the actual action will be able to make changes directly without change requests.
 

website/docs/reference/environments.md

@@ -13,17 +13,17 @@ Environments were released in Unleash v4.3.0.
     <iframe src="https://www.loom.com/embed/95239e875bbc4e09a5c5833e1942e4b0" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style={{position: 'absolute', top: '0', left: '0', width: '100%', height: '100%'}}></iframe>
 </div>
 
-Environments is a new way to organize activation strategy configurations for feature toggles into separate environments. In Unleash, a feature lives across all your environments — after all, the goal is to get the new feature released as soon as possible — but it makes sense to configure the activation differently per environment. You might want the feature enabled for everyone in development, but only for yourself in production, for instance.
+Environments is a new way to organize activation strategy configurations for feature flags into separate environments. In Unleash, a feature lives across all your environments — after all, the goal is to get the new feature released as soon as possible — but it makes sense to configure the activation differently per environment. You might want the feature enabled for everyone in development, but only for yourself in production, for instance.
 
 Previously, Unleash Enterprise could use [strategy constraints](../reference/strategy-constraints.md) to control the rollout across environments. With the new environments feature, this is no longer necessary. Now all activation strategies belong to an explicit environment instead.
 
-Further, connected applications will use environment-scoped API keys to make sure they only download feature toggle configurations for the environment they are running in.
+Further, connected applications will use environment-scoped API keys to make sure they only download feature flag configurations for the environment they are running in.
 
 Finally, metrics have also been upgraded to record the environment. This, in turn, means that Unleash can display usage metrics per environment.
 
-Despite this being a shift in how Unleash works, everything will continue to work exactly how it did for existing users. For backwards compatibility, we have created an environment named "default" that will contain all of the existing toggles and API keys. Read more about that in [the migration section](#migration).
+Despite this being a shift in how Unleash works, everything will continue to work exactly how it did for existing users. For backwards compatibility, we have created an environment named "default" that will contain all of the existing flags and API keys. Read more about that in [the migration section](#migration).
 
-![A graph showing how environments work. Each project can have multiple features, and each feature can have different activation strategies in each of its environments.](/img/environments_overview.svg 'A feature toggle exists across all environments, but take different activation strategies per environment.')
+![A graph showing how environments work. Each project can have multiple features, and each feature can have different activation strategies in each of its environments.](/img/environments_overview.svg 'A feature flag exists across all environments, but take different activation strategies per environment.')
 
 ## Environment types
 
@@ -51,23 +51,23 @@ If you are on v4.2, you also need to have the environment feature enabled (if yo
 
 If you are on v4.3 or later, environments are already enabled for you.
 
-Note that in order to enable an environment for a feature toggle, you must first add activation strategies for that environment. You cannot enable an environment without activation strategies.
+Note that in order to enable an environment for a feature flag, you must first add activation strategies for that environment. You cannot enable an environment without activation strategies.
 
 ### Step 1: Enable new environments for your Project
 
 Navigate to the project and choose the “environments” tab.
 
-![A project view showing the Environments tab. The UI displays three environment toggles: "default", "development", and "production". The "default" environment is enabled.](/img/environments_configure.png 'Configure environment for this project')
+![A project view showing the Environments tab. The UI displays three environment flags: "default", "development", and "production". The "default" environment is enabled.](/img/environments_configure.png 'Configure environment for this project')
 
 ### Step 2: Configure activation strategies for the new environment
 
-From the “feature toggle view” you will now be able to configure activation strategies per environment. You can also enable and disable environments here. Remember that an environment must have activation strategies before you can enable it.
+From the “feature flag view” you will now be able to configure activation strategies per environment. You can also enable and disable environments here. Remember that an environment must have activation strategies before you can enable it.
 
-![A feature toggle strategies tab showing three different environments, of which one is active. The UI displays data about the currently selected environment, ](/img/environments_strategies.png 'Add strategy configuration per environment')
+![A feature flag strategies tab showing three different environments, of which one is active. The UI displays data about the currently selected environment, ](/img/environments_strategies.png 'Add strategy configuration per environment')
 
 ### Step 3: Create environment specific API keys
 
-In order for the SDK to download the feature toggle configuration for the correct environment you will need to create an API token for a defined environment.
+In order for the SDK to download the feature flag configuration for the correct environment you will need to create an API token for a defined environment.
 
 ![An API key creation form. The form's fields are "username", "token type", "project", and, crucially, "environment". The development environment is selected.](/img/environments_api_keys.png 'Create Environment specific API Keys')
 
@@ -79,7 +79,7 @@ Environment cloning was made available in Unleash 4.19.
 
 :::
 
-Unleash environments can be cloned. Cloning an environment creates a **new** environment based on the selected source environment. When cloning an environment, you select any number of projects whose feature toggle configurations will also be cloned. These projects will have identical configurations for the source and target environments. However, the environments can then be configured independently and will not stay in sync with each other.
+Unleash environments can be cloned. Cloning an environment creates a **new** environment based on the selected source environment. When cloning an environment, you select any number of projects whose feature flag configurations will also be cloned. These projects will have identical configurations for the source and target environments. However, the environments can then be configured independently and will not stay in sync with each other.
 
 When cloning an environment, you must give the new environment
 - a name
@@ -102,7 +102,7 @@ If you're currently using strategy constraints together with the “environment
 
 ### Integrations
 
-We have made some slight changes to events related to feature toggles: there's one deprecation and several new event types. Most of the new events contain _project_ and _environment_ data.
+We have made some slight changes to events related to feature flags: there's one deprecation and several new event types. Most of the new events contain _project_ and _environment_ data.
 
 To avoid missing important updates, you will also need to update your integration configuration to subscribe to the new events.
 
@@ -112,22 +112,22 @@ To avoid missing important updates, you will also need to update your integratio
 
 **New Events**
 
-- **FEATURE-METADATA-UPDATED** - The feature toggle metadata was updated (across all environments).
+- **FEATURE-METADATA-UPDATED** - The feature flag metadata was updated (across all environments).
-- **FEATURE-STRATEGY-ADD**¹ - An activation strategy was added to a feature toggle in an environment. The _data_ will contain the updated strategy configuration.
+- **FEATURE-STRATEGY-ADD**¹ - An activation strategy was added to a feature flag in an environment. The _data_ will contain the updated strategy configuration.
-- **FEATURE-STRATEGY-UPDATE**¹ - An activation strategy was updated for a feature toggle. The _data_ will contain the updated strategy configuration.
+- **FEATURE-STRATEGY-UPDATE**¹ - An activation strategy was updated for a feature flag. The _data_ will contain the updated strategy configuration.
-- **FEATURE-STRATEGY-REMOVE**¹ - An activation strategy was removed for a feature toggle.
+- **FEATURE-STRATEGY-REMOVE**¹ - An activation strategy was removed for a feature flag.
-- **FEATURE-ENVIRONMENT-ENABLED**¹ - Signals that a feature toggle has been _enabled_ in a defined environment.
+- **FEATURE-ENVIRONMENT-ENABLED**¹ - Signals that a feature flag has been _enabled_ in a defined environment.
-- **FEATURE-ENVIRONMENT-DISABLED**¹ - Signals that a feature toggle has been _disabled_ in a defined environment.
+- **FEATURE-ENVIRONMENT-DISABLED**¹ - Signals that a feature flag has been _disabled_ in a defined environment.
-- **FEATURE-PROJECT-CHANGE**¹ - The feature toggle was moved to a new project.
+- **FEATURE-PROJECT-CHANGE**¹ - The feature flag was moved to a new project.
 
 > 1. These feature events will contain _project_ and _environment_ as part of the event metadata.
 
 ### API
 
-In order to support configuration per environment we had to rebuild our feature toggle admin API to account for environments as well. This means that we're making the following changes to the API:
+In order to support configuration per environment we had to rebuild our feature flag admin API to account for environments as well. This means that we're making the following changes to the API:
 
-- **/api/admin/features** - _deprecated (scheduled for removal in Unleash v5.0). The [old feature toggles admin API](/reference/api/legacy/unleash/admin/features.md) still works, but strategy configuration will be assumed to target the “default” environment._
+- **/api/admin/features** - _deprecated (scheduled for removal in Unleash v5.0). The [old feature flags admin API](/reference/api/legacy/unleash/admin/features.md) still works, but strategy configuration will be assumed to target the “default” environment._
-- **/api/admin/projects/:projectId/features** - New feature API to be used for feature toggles which also adds support for environments. See [the documentation](/reference/api/legacy/unleash/admin/features.md) to learn more.
+- **/api/admin/projects/:projectId/features** - New feature API to be used for feature flags which also adds support for environments. See [the documentation](/reference/api/legacy/unleash/admin/features.md) to learn more.
 
 ## Plan Differences
 

website/docs/reference/event-log.md

@@ -4,18 +4,18 @@ title: Event Log
 
 The event log lets you track changes in Unleash. It lists _what_ changed, _when_ it changed, and _who_ performed the change.
 
-## Feature toggle log {#event-log-per-feature-toggle}
+## Feature flag log {#event-log-per-feature-toggle}
 
-<span id="audit-log-per-feature-toggle" data-reason="backwards-compatibility"></span>
+<span id="audit-log-per-feature-flag" data-reason="backwards-compatibility"></span>
 
-Each feature toggle has its own event log. The event log is available under the "Event log" tab in the tab view.
+Each feature flag has its own event log. The event log is available under the "Event log" tab in the tab view.
 
-![The event log for a feature toggle. The "Event log" tab is highlighted and the UI shows the most recent changes, including a JSON diff and the change details.](/img/unleash-toggle-history.png)
+![The event log for a feature flag. The "Event log" tab is highlighted and the UI shows the most recent changes, including a JSON diff and the change details.](/img/unleash-toggle-history.png)
 
 ## Global Event Log {#global-event-log}
 
 <span id="global-audit-log" data-reason="backwards-compatibility"></span>
 
-Unleash also keeps an event log across all toggles and activation strategies, tracking all changes. You access the global event log via the “event log”, which you can find in the drawer menu. The global event log is only accessible by users with instance admin access.
+Unleash also keeps an event log across all flags and activation strategies, tracking all changes. You access the global event log via the “event log”, which you can find in the drawer menu. The global event log is only accessible by users with instance admin access.
 
 ![The global event log and how to get there. It shows a number of events and their changes as well as the navigation steps: use the admin menu and navigate to "event history".](/img/global_audit_log.png)

website/docs/reference/feature-toggle-types.md

@@ -1,27 +1,27 @@
 ---
-title: Feature Toggle Types
+title: Feature Flag Types
 ---
 
 > This feature was introduced in _Unleash v3.5.0_.
 
-You can use feature toggles to support different use cases, each with their own specific needs. Heavily inspired by [Pete Hodgson's article on feature toggles](https://martinfowler.com/articles/feature-toggles.html), Unleash introduced the concept of feature toggle types in version `3.5.0`.
+You can use feature flags to support different use cases, each with their own specific needs. Heavily inspired by [Pete Hodgson's article on feature flags](https://martinfowler.com/articles/feature-toggles.html), Unleash introduced the concept of feature flag types in version `3.5.0`.
 
-A feature toggle's type affects only two things:
+A feature flag's type affects only two things:
-1. It gives the toggle an appropriate icon
+1. It gives the flag an appropriate icon
-2. The toggle's expected lifetime changes
+2. The flag's expected lifetime changes
 
-Aside from this, there are no differences between the toggle types and you can always change the type of a toggle after you have created it.
+Aside from this, there are no differences between the flag types and you can always change the type of a flag after you have created it.
 
-Classifying feature toggles by their type makes it easier for you manage them: the toggles get different icons in the toggle list and you can sort the toggles by their types.
+Classifying feature flags by their type makes it easier for you manage them: the flags get different icons in the flag list and you can sort the flags by their types.
 
-![Five feature toggles, each of a different type, showing the different icons that Unleash uses for each toggle type.](/img/toggle_type_icons.png "Feature toggle type icons")
+![Five feature flags, each of a different type, showing the different icons that Unleash uses for each flag type.](/img/toggle_type_icons.png "Feature flag type icons")
 
-A toggle's type also helps Unleash understand the [toggle's expected lifetime](#expected-lifetimes).
+A flag's type also helps Unleash understand the [flag's expected lifetime](#expected-lifetimes).
-## Feature toggle types
+## Feature flag types
 
-Here's the list of the feature toggle types that Unleash supports together with their intended use case and expected lifetime:
+Here's the list of the feature flag types that Unleash supports together with their intended use case and expected lifetime:
 
-| Feature toggle type | Used to ...                                                                                                                                                       | Expected lifetime |
+| Feature flag type | Used to ...                                                                                                                                                       | Expected lifetime |
 |---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|
 | Release             | Enable trunk-based development for teams practicing Continuous Delivery.                                                                                          | 40 days           |
 | Experiment          | Perform multivariate or A/B testing.                                                                                                                              | 40 days           |
@@ -33,25 +33,25 @@ Here's the list of the feature toggle types that Unleash supports together with
 
 :::info
 
-The ability to update a feature toggle type's expected lifetime is currently in development. We expect to release it in one of the upcoming releases.
+The ability to update a feature flag type's expected lifetime is currently in development. We expect to release it in one of the upcoming releases.
 
 :::
 
-A feature toggle's expected lifetime is an indicator of how long Unleash expects toggles of that type to be around. Some feature toggles are meant to live for a few weeks as you work on new functionality, while others stick around for much longer. As a part of good code hygiene, you should clean up your feature toggles when they have served their purpose. This is further explored in the document on [technical debt](technical-debt.md).
+A feature flag's expected lifetime is an indicator of how long Unleash expects flags of that type to be around. Some feature flags are meant to live for a few weeks as you work on new functionality, while others stick around for much longer. As a part of good code hygiene, you should clean up your feature flags when they have served their purpose. This is further explored in the document on [technical debt](technical-debt.md).
 
-Each feature toggle type in Unleash has an assigned expected lifetime, after which the system will consider this feature _potentially stale_. The reasoning behind each type's expected lifetime is detailed in this [blog post on best practices for feature toggle lifetimes](https://www.getunleash.io/blog/feature-toggle-life-time-best-practices).
+Each feature flag type in Unleash has an assigned expected lifetime, after which the system will consider this feature _potentially stale_. The reasoning behind each type's expected lifetime is detailed in this [blog post on best practices for feature flag lifetimes](https://www.getunleash.io/blog/feature-toggle-life-time-best-practices).
 
 Unleash admins can change the expected lifetime of Unleash's feature types from the Unleash configuration menu.
 
 
-## Deprecating feature toggles {#deprecate-a-feature-toggle}
+## Deprecating feature flags {#deprecate-a-feature-toggle}
 
-You can mark feature toggles as `stale`. This is a way to deprecate a feature toggle without removing the active configuration for connected applications. Use this to signal that you should stop using the feature in your applications. Stale toggles will show as stale in the ["technical debt dashboard"](technical-debt.md).
+You can mark feature flags as `stale`. This is a way to deprecate a feature flag without removing the active configuration for connected applications. Use this to signal that you should stop using the feature in your applications. Stale flags will show as stale in the ["technical debt dashboard"](technical-debt.md).
 
-When you mark a toggle as stale, Unleash will emit an event. You can use [an integration](integrations/integrations.md) to integrate this with your systems, for instance to post a message in a Slack channel.
+When you mark a flag as stale, Unleash will emit an event. You can use [an integration](integrations/integrations.md) to integrate this with your systems, for instance to post a message in a Slack channel.
 
 Additionally, with some extra work, you can also use the `stale` property to:
 
-- Inform developers that a toggle is stale _while_ they're developing.
+- Inform developers that a flag is stale _while_ they're developing.
-- Break a project build if the code contains stale feature toggles.
+- Break a project build if the code contains stale feature flags.
-- Send automatic PRs to remove usage of toggles that have served their purpose.
+- Send automatic PRs to remove usage of flags that have served their purpose.

website/docs/reference/feature-toggle-variants.md

@@ -1,9 +1,9 @@
 ---
-title: Feature Toggle Variants (deprecated)
+title: Feature Flag Variants (deprecated)
 ---
 :::warning
 
-Feature Toggle Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants.md). 
+Feature Flag Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants.md). 
 Only features that have existing feature environment variants will keep them. 
 If you'd like to keep the old variants in your hosted instance [contact us](https://slack.unleash.run) for further assistance.
 
@@ -11,23 +11,23 @@ If you'd like to keep the old variants in your hosted instance [contact us](http
 
 :::info Availability
 
-**Feature toggle variants** were first introduced in Unleash 3.2.
+**Feature flag variants** were first introduced in Unleash 3.2.
 In Unleash 4.21, variants were updated to be **environment-dependent**, meaning the same feature could have different variant configurations in different environments.
 
 :::
 
-Every toggle in Unleash can have something called _variants_. Where _feature toggles_ allow you to decide which users get access to a feature, _toggle variants_ allow you to further split those users into segments. Say, for instance, that you're testing out a new feature, such as an alternate sign-up form. The feature toggle would expose the form only to a select group of users. The variants could decide whether the user sees a blue or a green submit button on that form.
+Every flag in Unleash can have something called _variants_. Where _feature flags_ allow you to decide which users get access to a feature, _flag variants_ allow you to further split those users into segments. Say, for instance, that you're testing out a new feature, such as an alternate sign-up form. The feature flag would expose the form only to a select group of users. The variants could decide whether the user sees a blue or a green submit button on that form.
 
 Variants facilitate A/B testing and experimentation by letting you create controlled and measurable experiments. Check [our blog post on using Unleash for A/B/n experiments](https://www.getunleash.io/blog/a-b-n-experiments-in-3-simple-steps) for some more insights into how you can set it up.
 
 ## What are variants?
 
-Whenever you create a feature toggle, you can assign it any number of _variants_. This is commonly done in cases where you want to serve your users different versions of a feature to see which performs better. A feature can have different variants in each of its environments.
+Whenever you create a feature flag, you can assign it any number of _variants_. This is commonly done in cases where you want to serve your users different versions of a feature to see which performs better. A feature can have different variants in each of its environments.
 
 A variant has four components that define it:
 - a **name**:
 
-    This must be unique among the toggle's variants in the specified environment. When working with a feature with variants in a client, you will typically use the variant's name to find out which variant it is.
+    This must be unique among the flag's variants in the specified environment. When working with a feature with variants in a client, you will typically use the variant's name to find out which variant it is.
 
 - a **weight**:
 
@@ -42,7 +42,7 @@ A variant has four components that define it:
 
     Overrides let you specify that certain users (as identified either by their user ID or by another [custom stickiness](./stickiness.md) value) will always get this variant, regardless of the variant's weight.
 
-![A form for adding new variants. It has fields for name, weight, payload, and overrides.](/img/variant-creation-form.png 'Creating a new toggle variant')
+![A form for adding new variants. It has fields for name, weight, payload, and overrides.](/img/variant-creation-form.png 'Creating a new flag variant')
 
 ### Variant weight
 
@@ -108,11 +108,11 @@ Variant stickiness is calculated on the received user and context, as described
 
 In the Unleash UI, you can configure variants by navigating to the feature view, and then choosing the 'Variants' tab.
 
-![toggle_variants](/img/variants.png 'Feature Toggle Variants')
+![flag_variants](/img/variants.png 'Feature Flag Variants')
 
 ## The `disabled` variant
 
-When a toggle has no variants or when a toggle is disabled for a user, Unleash will return it with variant data that looks like this:
+When a flag has no variants or when a flag is disabled for a user, Unleash will return it with variant data that looks like this:
 
 ```json
 {
@@ -127,7 +127,7 @@ Note: The actual representation of the built-in fallback variant in the client S
 
 ## Client SDK Support {#client-sdk-support}
 
-To make use of toggle variants, you need to use a compatible client. Client SDK with variant support:
+To make use of flag variants, you need to use a compatible client. Client SDK with variant support:
 
 - [unleash-client-node](https://github.com/Unleash/unleash-client-node) (from v3.2.0)
 - [unleash-client-java](https://github.com/Unleash/unleash-client-java) (from v3.2.0)

website/docs/reference/feature-toggles.mdx

@@ -1,39 +1,39 @@
 ---
-title: Feature Toggles
+title: Feature Flags
 ---
 
-Feature toggles are the central concept that we built Unleash around. In Unleash, feature toggles are organized within [projects](../reference/projects.md). Feature toggles can have different [activation strategies](../reference/activation-strategies.md) for each of their project's [environments](../reference/environments.md), and can also be given [variants](../reference/feature-toggle-variants.md) to facilitate A/B testing.
+Feature flags are the central concept that we built Unleash around. In Unleash, feature flags are organized within [projects](../reference/projects.md). Feature flags can have different [activation strategies](../reference/activation-strategies.md) for each of their project's [environments](../reference/environments.md), and can also be given [variants](../reference/feature-toggle-variants.md) to facilitate A/B testing.
 
 ## Configuration options
 
-Each feature toggle has the following configuration options
+Each feature flag has the following configuration options
 
 | Option | Required? | Default value | Description |
 | --- | --- | --- | --- |
-| name | Yes | N/A | The feature toggle's name. Must be URL-friendly according to [section 2.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) and must be unique within your Unleash instance. Must be between 1 and 100 characters long, inclusive. |
+| name | Yes | N/A | The feature flag's name. Must be URL-friendly according to [section 2.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) and must be unique within your Unleash instance. Must be between 1 and 100 characters long, inclusive. |
-| feature toggle type | Yes | Release | The [feature toggle's type](../reference/feature-toggle-types.md). |
+| feature flag type | Yes | Release | The [feature flag's type](../reference/feature-toggle-types.md). |
-| project | Yes | The [default project](../reference/projects.md#the-default-project). When created from a project page in the admin UI, that project will be the default value instead. | The [project](../reference/projects.md) that should contain the feature toggle. |
+| project | Yes | The [default project](../reference/projects.md#the-default-project). When created from a project page in the admin UI, that project will be the default value instead. | The [project](../reference/projects.md) that should contain the feature flag. |
-| description | No | N/A | A description of the feature toggle's purpose. |
+| description | No | N/A | A description of the feature flag's purpose. |
-| enable impression data | Yes | No | Whether to enable [impression data](../reference/impression-data.md) for this toggle or not. |
+| enable impression data | Yes | No | Whether to enable [impression data](../reference/impression-data.md) for this flag or not. |
 
 ## Environments
 
-You probably won't want to use the same configuration to enable a toggle in development as you do in production. That's why feature toggles have different activation strategy configurations for each environment.
+You probably won't want to use the same configuration to enable a flag in development as you do in production. That's why feature flags have different activation strategy configurations for each environment.
 
-You can enable and disable a toggle independently in each of the [project's environments](../reference/projects.md#projects-and-environments). When you disable a toggle in an environment, it will always evaluate to false in that environment. When you enable a toggle in an environment, the toggle will evaluate to true or false depending on its activation strategies.
+You can enable and disable a flag independently in each of the [project's environments](../reference/projects.md#projects-and-environments). When you disable a flag in an environment, it will always evaluate to false in that environment. When you enable a flag in an environment, the flag will evaluate to true or false depending on its activation strategies.
 
 Refer to the [documentation on environments](../reference/environments.md) for more details on how environments work.
 
 ## Activation strategies
 
-To enable a feature in an environment, you must assign it at least one activation strategy. A feature toggle's activation strategies determine whether the toggle gets enabled for a particular [Unleash context](../reference/unleash-context.md) (typically a user). When using multiple strategies in a single environment, only a single strategy needs to evaluate to true for the toggle to get enabled for a user. Whenever Unleash evaluates a toggle, it will evaluate strategies in the current environment until one of them resolves to true. If no strategies resolve to true, then the toggle's value is false.
+To enable a feature in an environment, you must assign it at least one activation strategy. A feature flag's activation strategies determine whether the flag gets enabled for a particular [Unleash context](../reference/unleash-context.md) (typically a user). When using multiple strategies in a single environment, only a single strategy needs to evaluate to true for the flag to get enabled for a user. Whenever Unleash evaluates a flag, it will evaluate strategies in the current environment until one of them resolves to true. If no strategies resolve to true, then the flag's value is false.
 
 Refer to the [activation strategies documentation](../reference/activation-strategies.md) for a detailed description of all the built-in strategies.
 
 ## Variants
 
-[Variants](../reference/feature-toggle-variants.md) adds another dimension of flexibility to feature toggles. Each feature toggle can be assigned any number of variants which will then get distributed amongst your users based on your choice of [context field](../reference/unleash-context.md#structure). You can find out more about variants in the [variants docs](../reference/feature-toggle-variants.md).
+[Variants](../reference/feature-toggle-variants.md) adds another dimension of flexibility to feature flags. Each feature flag can be assigned any number of variants which will then get distributed amongst your users based on your choice of [context field](../reference/unleash-context.md#structure). You can find out more about variants in the [variants docs](../reference/feature-toggle-variants.md).
 
-### Creating toggles with payloads
+### Creating flags with payloads
 
-While variants are most often used for A/B testing and the like, you can also use variants to assign a constant payload to a toggle. If you give a toggle only a single variant and that variant has a payload, then all users variants will receive that payload.
+While variants are most often used for A/B testing and the like, you can also use variants to assign a constant payload to a flag. If you give a flag only a single variant and that variant has a payload, then all users variants will receive that payload.

website/docs/reference/front-end-api.md

@@ -48,6 +48,6 @@ You can create appropriate token, with type `FRONTEND` on `<YOUR_UNLEASH_URL>/ap
 
 Internally, Unleash creates a new Unleash client for each token it receives. Each client is configured with the project and environment specified in the token.
 
-Each client updates its feature toggle configuration at a specified refresh interval plus a random offset between 0 and 10 seconds. By default, the refresh interval is set to 10 seconds. The random offset is used to stagger incoming requests to avoid a large number of clients all querying the database simultaneously. A new, random offset is used for every update.
+Each client updates its feature flag configuration at a specified refresh interval plus a random offset between 0 and 10 seconds. By default, the refresh interval is set to 10 seconds. The random offset is used to stagger incoming requests to avoid a large number of clients all querying the database simultaneously. A new, random offset is used for every update.
 
 The refresh interval is specified in milliseconds and can be set by using the `FRONTEND_API_REFRESH_INTERVAL_MS` environment variable or by using the `frontendApi.refreshIntervalInMs` configuration option in code.

website/docs/reference/impression-data.md

@@ -8,21 +8,21 @@ The impression data feature was introduced in **Unleash 4.7**. It is available i
 
 :::
 
-Unleash can provide you with **impression data** about the toggles in your application. Impression data contains information about a specific feature toggle activation check: The client SDK will emit an **impression event** when it calls `isEnabled` or `getVariant`. Some front-end SDKs emit impression events only when a toggle is enabled.
+Unleash can provide you with **impression data** about the flags in your application. Impression data contains information about a specific feature flag activation check: The client SDK will emit an **impression event** when it calls `isEnabled` or `getVariant`. Some front-end SDKs emit impression events only when a flag is enabled.
 
-:::caution Front-end SDKs and disabled toggles
+:::caution Front-end SDKs and disabled flags
 
-Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](../generated/unleash-proxy.md) or the [Unleash front-end API](../reference/front-end-api.md) would **not** emit impression events when a toggle is disabled.
+Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](../generated/unleash-proxy.md) or the [Unleash front-end API](../reference/front-end-api.md) would **not** emit impression events when a flag is disabled.
 
-This is because impression data is a **per-toggle** setting and the Proxy and front-end API only transmit information about toggles that are enabled. As such, the SDK will never know that it should emit an impression event if a toggle is disabled.
+This is because impression data is a **per-flag** setting and the Proxy and front-end API only transmit information about flags that are enabled. As such, the SDK will never know that it should emit an impression event if a flag is disabled.
 
-Some of the front-end SDKs now include a include a configuration property that lets you turn on impression data for all toggles regardless of whether they're enabled or not.
+Some of the front-end SDKs now include a include a configuration property that lets you turn on impression data for all flags regardless of whether they're enabled or not.
 
 :::
 
-Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature toggle and the related [Unleash Context](../reference/unleash-context.md).
+Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature flag and the related [Unleash Context](../reference/unleash-context.md).
 
-Impression data is **opt-in on a per-toggle basis**. Unleash will not emit impression events for toggles not marked as such. Once you've turned impression data on for a toggle, you can start listening for impression events in your client SDK.
+Impression data is **opt-in on a per-flag basis**. Unleash will not emit impression events for flags not marked as such. Once you've turned impression data on for a flag, you can start listening for impression events in your client SDK.
 
 ## Impression event data
 
@@ -40,8 +40,8 @@ This table describes all the properties on the impression events:
 | `eventType` | The type of the event: `isEnabled` or `getVariant` | All |
 | `eventId` | A globally unique id (GUID) assigned to this event. | All |
 | `context` | A representation of the current [Unleash Context](../reference/unleash-context.md). | All |
-| `enabled` | Whether the toggle was enabled or not at when the client made the request. | All |
+| `enabled` | Whether the flag was enabled or not at when the client made the request. | All |
-| `featureName` | The name of the feature toggle. | All |
+| `featureName` | The name of the feature flag. | All |
 | `variant` | The name of the active variant | `getVariant` events only |
 
 ### Example `isEnabled` event {#example-isenabled}
@@ -56,7 +56,7 @@ This table describes all the properties on the impression events:
     environment: 'default'
   },
   enabled: true,
-  featureName: 'my-feature-toggle',
+  featureName: 'my-feature-flag',
 }
 ```
 
@@ -72,22 +72,22 @@ This table describes all the properties on the impression events:
     environment: 'default'
   },
   enabled: true,
-  featureName: 'my-feature-toggle',
+  featureName: 'my-feature-flag',
   variant: 'variantA'
 }
 ```
 
 ## Enabling impression data
 
-Impression data is strictly an **opt-in** feature and must be enabled on a **per-toggle basis**. You can enable and disable it both when you create a toggle and when you edit a toggle.
+Impression data is strictly an **opt-in** feature and must be enabled on a **per-flag basis**. You can enable and disable it both when you create a flag and when you edit a flag.
 
-You can enable impression data via the impression data toggle in the admin UI's toggle creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data.mdx#step-1).
+You can enable impression data via the impression data flag in the admin UI's flag creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data.mdx#step-1).
 
-![A feature toggle creation form. At the end of the form is a heading that says "Impression data", a short paragraph that describes the feature, and a toggle to opt in or out of it.](/img/create_feat_impression.png)
+![A feature flag creation form. At the end of the form is a heading that says "Impression data", a short paragraph that describes the feature, and a flag to opt in or out of it.](/img/create_feat_impression.png)
 
 ## Example setup
 
-The exact setup will vary depending on your [client SDK](../reference/sdks/index.md). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-toggle" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready.
+The exact setup will vary depending on your [client SDK](../reference/sdks/index.md). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-flag" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready.
 
 ```js
 const unleash = new UnleashClient({
@@ -99,7 +99,7 @@ const unleash = new UnleashClient({
 unleash.start();
 
 unleash.on('ready', () => {
-  unleash.isEnabled('my-feature-toggle');
+  unleash.isEnabled('my-feature-flag');
 });
 
 unleash.on('impression', (event) => {

website/docs/reference/playground.mdx

@@ -15,13 +15,13 @@ The Unleash playground is available in all Unleash versions from Unleash 4.14 on
 
 ![The Unleash Playground form and an indication of where in the nav menu it is located.](/img/playground-form.png)
 
-The unleash playground is a part of the Unleash Admin UI and an accompanying API. The playground lets you see which of your instance's feature toggles would be enabled for a given Unleash context. It has multiple uses, such as:
+The unleash playground is a part of the Unleash Admin UI and an accompanying API. The playground lets you see which of your instance's feature flags would be enabled for a given Unleash context. It has multiple uses, such as:
 
 -   Understanding how Unleash evaluates strategies, constraints, and segments.
--   Debugging Unleash contexts and toggles behaving differently from what you expect.
+-   Debugging Unleash contexts and flags behaving differently from what you expect.
 -   Tailoring a set of strategies for given contexts.
 
-Each feature toggle will contain info on whether it was enabled or not and which variant it was assigned. Later versions of the playground also contain [detailed evaluation results](#detailed-evaluation-results) to help you understand exactly why the feature was enabled or disabled.
+Each feature flag will contain info on whether it was enabled or not and which variant it was assigned. Later versions of the playground also contain [detailed evaluation results](#detailed-evaluation-results) to help you understand exactly why the feature was enabled or disabled.
 
 ## Configuring the query
 
@@ -62,7 +62,7 @@ You can add any fields you want to the context used for the evaluation, and you
 
 ![Playground results: a table of feature names and whether they're enabled or not.](/img/playground-results.png)
 
-The playground's response contains a list of all the feature toggles that have been evaluated based on your configured [environments, projects](#environments-and-projects) and [context](#the-unleash-context). The full response will contain results for all combinations of context fields and all environments that you selected.
+The playground's response contains a list of all the feature flags that have been evaluated based on your configured [environments, projects](#environments-and-projects) and [context](#the-unleash-context). The full response will contain results for all combinations of context fields and all environments that you selected.
 
 In the UI, the playground displays the features in a table. Each row of the table corresponds to a single feature. The table has a separate column for each of the environments that you selected for your query.
 

website/docs/reference/projects.md

@@ -17,21 +17,21 @@ All users get access to the default project. You cannot delete this project. You
 
 ## Understanding purpose of projects {#understanding-purpose-of-projects}
 
-Projects are a way to organize your feature toggles within Unleash. Within a large organization, having multiple feature toggles, staying on top of the feature toggles might become a challenge. Every feature toggle will be part of a project. Projects can be linked to a development team or to functional modules within the software.
+Projects are a way to organize your feature flags within Unleash. Within a large organization, having multiple feature flags, staying on top of the feature flags might become a challenge. Every feature flag will be part of a project. Projects can be linked to a development team or to functional modules within the software.
 
-A common pattern is to organize the feature toggles according to key areas of the application, e.g. “Basic user process” and “Advanced user process”. This is illustrated below.
+A common pattern is to organize the feature flags according to key areas of the application, e.g. “Basic user process” and “Advanced user process”. This is illustrated below.
 
 ![A diagram with two boxes labeled "Basic user process" and "Advanced user process", respectively. The former contains features "New login" and "Winter theme enablement", the latter "New in-app purchase" and "Updated invoice repository".](/img/project_concept.png)
 
 ## Projects and environments
 
-You can configure which [environments](./environments.md) should be available within a project. By default, all globally available environments are available. You can only enable/disable a feature toggle for the environments you configure for a project.
+You can configure which [environments](./environments.md) should be available within a project. By default, all globally available environments are available. You can only enable/disable a feature flag for the environments you configure for a project.
 
 Within the admin UI, the projects are available under the "environments" tab of the project page. Changing them requires the project owner role.
 
 ## Creating a new project {#creating-a-new-project}
 
-When you log into Unleash for the first time, there is a Default project already created. All feature toggles are included in the Default project, unless explicitly set to a different one.
+When you log into Unleash for the first time, there is a Default project already created. All feature flags are included in the Default project, unless explicitly set to a different one.
 
 From the top-line menu – click on “Projects”
 
@@ -55,7 +55,7 @@ The configuration of a new Project is now available. the following input is avai
 
 ## Deleting an existing project {#deleting-an-existing-project}
 
-To keep your feature toggles clean, removing deprecated projects is important. From the overview of Projects –
+To keep your feature flags clean, removing deprecated projects is important. From the overview of Projects –
 
 1. In the top right of the project card, find the project menu represented by three vertical dots.
 
@@ -65,39 +65,39 @@ To keep your feature toggles clean, removing deprecated projects is important. F
 
 ![A list of projects. Each project has three vertical dots — a kebab menu — next to it, which exposes a menu with the "Edit project" and "Delete project" options when interacted with.](/img/projects_delete_button.png)
 
-## Filter feature toggles on projects {#filter-feature-toggles-on-projects}
+## Filter feature flags on projects {#filter-feature-toggles-on-projects}
 
-When browsing the feature toggles in Unleash, you might want to filter the view by looking only at the ones included in the project of interest. This is possible from the Feature toggle overview.
+When browsing the feature flags in Unleash, you might want to filter the view by looking only at the ones included in the project of interest. This is possible from the Feature flag overview.
 
-From the UI top navigation menu, choose "Feature toggles".
+From the UI top navigation menu, choose "Feature flags".
 
-![The Unleash Admin UI navigation menu with the "Feature toggles" option highlighted by a red arrow.](/img/projects_menu.png)
+![The Unleash Admin UI navigation menu with the "Feature flags" option highlighted by a red arrow.](/img/projects_menu.png)
 
-The list of features toggles can be filtered on the project of your choice. By default, all feature toggles are listed in the view. You can use the search to filter to a specific project or even for multiple projects in the same time if you need.
+The list of features flags can be filtered on the project of your choice. By default, all feature flags are listed in the view. You can use the search to filter to a specific project or even for multiple projects in the same time if you need.
 
-![The feature toggle list with toggles scoped to the "fintech" project. The filter is activated by using a form control.](/img/project_select.png)
+![The feature flag list with flags scoped to the "fintech" project. The filter is activated by using a form control.](/img/project_select.png)
 
 In the search you can type "project:specific-name" to filter that project only.
 
-![The feature toggle list with an overlay listing all the projects available. You can select a project and the list will update with the toggles belonging to that project.](/img/projects_select_dropdown.png)
+![The feature flag list with an overlay listing all the projects available. You can select a project and the list will update with the flags belonging to that project.](/img/projects_select_dropdown.png)
 
-The view will now be updated with the filtered feature toggles.
+The view will now be updated with the filtered feature flags.
 
-## Assigning project to a new feature toggle {#assigning-project-to-a-new-feature-toggle}
+## Assigning project to a new feature flag {#assigning-project-to-a-new-feature-toggle}
 
-When you create a new feature toggle, you can choose which project to create it in. The default project is whatever project you are currently configuring.
+When you create a new feature flag, you can choose which project to create it in. The default project is whatever project you are currently configuring.
 
-![A form to create a toggle. An arrow points to an input labeled "project".](/img/projects_change_project.png)
+![A form to create a flag. An arrow points to an input labeled "project".](/img/projects_change_project.png)
 
 All available projects are available from the drop-down menu.
 
-![A form to create a toggle. The "project" input is expanded to show projects you can create the toggle in.](/img/projects_toggle_project_dropdown.png)
+![A form to create a flag. The "project" input is expanded to show projects you can create the flag in.](/img/projects_toggle_project_dropdown.png)
 
-## Change project for an existing feature toggle {#change-project-for-an-existing-feature-toggle}
+## Change project for an existing feature flag {#change-project-for-an-existing-feature-toggle}
 
-If you want to change which project a feature toggle belongs to, you can change that from the feature toggle's configuration page. Under the _settings_ tab, choose the _project_ option and choose the new project from the dropdown menu.
+If you want to change which project a feature flag belongs to, you can change that from the feature flag's configuration page. Under the _settings_ tab, choose the _project_ option and choose the new project from the dropdown menu.
 
-![A feature toggle's settings tab. The project setting shows a dropdown to change projects.](/img/projects_existing_toggle_dropdown.png)
+![A feature flag's settings tab. The project setting shows a dropdown to change projects.](/img/projects_existing_toggle_dropdown.png)
 
 ## Project default strategy
 import Figure from '@site/src/components/Figure/Figure.tsx'

website/docs/reference/rbac.md

@@ -17,8 +17,8 @@ Unleash has two levels in its hierarchy of resources:
     - integration configurations
     - applications
     - users
-2. **Project resources** - Resources which are only available under a project. Today this is only “feature toggles” (but
+2. **Project resources** - Resources which are only available under a project. Today this is only “feature flags” (but
-   we expect more resources to live under a project in the future). A feature toggle will belong to only one single
+   we expect more resources to live under a project in the future). A feature flag will belong to only one single
    project. In Unleash-Open source there exists only a single project, the “default” project, while Unleash Enterprise
    supports multiple projects.
 
@@ -40,8 +40,8 @@ When you add a new user, you can assign them one of the root roles listed below.
 | **Admin**  | Root    | Users with the root admin role have superuser access to Unleash and can perform any operation within the Unleash platform.                                                                                                                                                                                                                                          | All versions       |
 | **Editor** | Root    | Users with the root editor role have access to most features in Unleash, but can not manage users and roles in the root scope. Editors will be added as project owners when creating projects and get superuser rights within the context of these projects. Users with the editor role will also get access to most permissions on the default project by default. | All versions       |
 | **Viewer** | Root    | Users with the root viewer role can only read root resources in Unleash. Viewers can be added to specific projects as project members. Users with the viewer role may not view API tokens.                                                                                                                                                                          | All versions       |
-| **Owner**  | Project | Users with the project owner role have full control over the project, and can add and manage other users within the project context, manage feature toggles within the project, and control advanced project features like archiving and deleting the project.                                                                                                      | Pro and Enterprise |
+| **Owner**  | Project | Users with the project owner role have full control over the project, and can add and manage other users within the project context, manage feature flags within the project, and control advanced project features like archiving and deleting the project.                                                                                                      | Pro and Enterprise |
-| **Member** | Project | Users with the project member role are allowed to view, create, and update feature toggles within a project, but have limited permissions in regards to managing the project's user access and can not archive or delete the project.                                                                                                                               | Pro and Enterprise |
+| **Member** | Project | Users with the project member role are allowed to view, create, and update feature flags within a project, but have limited permissions in regards to managing the project's user access and can not archive or delete the project.                                                                                                                               | Pro and Enterprise |
 
 ## Custom Root Roles
 
@@ -173,10 +173,10 @@ environments.
 | **settings read**                             | Read access to other project settings (included in "update the project" permission) |                                                                                                                                                              |                             
 | **settings write** | Write access to other project settings (included in "update the project" permission)                            
 | **delete the project**                        | Lets the user delete the project.                                                                                                                                                                                                                 |
-| **create feature toggles within the project** | Lets the user create feature toggles within the project and create variants for said toggle. Note that they **cannot assign strategies** to toggles without having the _create activation strategy_ permission for the corresponding environment. |
+| **create feature flags within the project** | Lets the user create feature flags within the project and create variants for said flag. Note that they **cannot assign strategies** to flags without having the _create activation strategy_ permission for the corresponding environment. |
-| **update feature toggles within the project** | Lets the user update feature toggle descriptions; mark toggles as stale / not stale; add, update, and remove toggle tags; and update toggle variants within the project.                                                                          |
+| **update feature flags within the project** | Lets the user update feature flag descriptions; mark flags as stale / not stale; add, update, and remove flag tags; and update flag variants within the project.                                                                          |
-| **delete feature toggles within the project** | Lets the user archive feature toggles within the project.                                                                                                                                                                                         |
+| **delete feature flags within the project** | Lets the user archive feature flags within the project.                                                                                                                                                                                         |
-| **change feature toggle project**             | Lets the user move toggles to other projects they have access to.                                                                                                                                                                                 |
+| **change feature flag project**             | Lets the user move flags to other projects they have access to.                                                                                                                                                                                 |
 | **create/edit variants**                      | Lets the user create and edit variants within the project. (Deprecated with v4.21 in favor of environment-specific permissions for working with variants[^1].)                                                                                    |
 
 ### Environment permissions
@@ -185,10 +185,10 @@ You can assign the following permissions on a per-environment level within the p
 
 | Permission                       | Description                                                                                                                                                                                                                                                                                                                                           |
 |----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **create activation strategies** | Lets the user assign feature toggle activation strategies within the environment.                                                                                                                                                                                                                                                                     |
+| **create activation strategies** | Lets the user assign feature flag activation strategies within the environment.                                                                                                                                                                                                                                                                       |
-| **update activation strategies** | Lets the user update feature toggle activation strategies within the environment.                                                                                                                                                                                                                                                                     |
+| **update activation strategies** | Lets the user update feature flag activation strategies within the environment.                                                                                                                                                                                                                                                                       |
-| **delete activation strategies** | Lets the user delete feature toggle activation strategies within the environment.                                                                                                                                                                                                                                                                     |
+| **delete activation strategies** | Lets the user delete feature flag activation strategies within the environment.                                                                                                                                                                                                                                                                       |
-| **enable/disable toggles**       | Lets the user enable and disable toggles within the environment.                                                                                                                                                                                                                                                                                      |
+| **enable/disable flags**         | Lets the user enable and disable flags within the environment.                                                                                                                                                                                                                                                                                        |
 | **update variants**              | Lets the user create, edit and remove variants within the environment.                                                                                                                                                                                                                                                                                |
 | **approve a change request**     | Lets the user approve [change requests](change-requests.md) in the environment.                                                                                                                                                                                                                                                                       |
 | **apply a change request**       | Lets the user apply change requests in the environment.                                                                                                                                                                                                                                                                                               |

website/docs/reference/stickiness.md

@@ -22,7 +22,7 @@ For instance: When using the [gradual rollout activation strategy](../reference/
 Custom stickiness is available starting from Unleash Enterprise v4.
 :::
 
-When using [the gradual rollout strategy](../reference/activation-strategies.md#gradual-rollout) or [feature toggle variants](./feature-toggle-variants.md), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context.md) as long as you have enabled custom stickiness for these fields.
+When using [the gradual rollout strategy](../reference/activation-strategies.md#gradual-rollout) or [feature flag variants](./feature-toggle-variants.md), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context.md) as long as you have enabled custom stickiness for these fields.
 
 :::note SDK compatibility
 
@@ -32,9 +32,9 @@ Custom stickiness is supported by all of our SDKs except for the Rust SDK. You c
 
 ### Enabling custom stickiness
 
-To enable custom stickiness on a field, navigate to the Create Context screen in the UI and find the field you want to enable. There's a "Custom stickiness" option at the bottom of the form. Enable this toggle and update the context field by pressing the "Update" button.
+To enable custom stickiness on a field, navigate to the Create Context screen in the UI and find the field you want to enable. There's a "Custom stickiness" option at the bottom of the form. Enable this flag and update the context field by pressing the "Update" button.
 
-![The Create Context screen in the Unleash UI. There's a toggle at the bottom to control custom stickiness.](/img/enable_custom_stickiness.png)
+![The Create Context screen in the Unleash UI. There's a flag at the bottom to control custom stickiness.](/img/enable_custom_stickiness.png)
 
 ## Project default stickiness
 

website/docs/reference/strategy-constraints.md

@@ -18,7 +18,7 @@ When using _advanced strategy constraints_ (any operator that isn't `IN` or `NOT
 
 :::
 
-**Strategy constraints** are conditions that must be satisfied for an [activation strategy](../reference/activation-strategies) to be evaluated for a feature toggle.
+**Strategy constraints** are conditions that must be satisfied for an [activation strategy](../reference/activation-strategies) to be evaluated for a feature flag.
 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**
@@ -52,7 +52,7 @@ By using [custom context fields](../reference/unleash-context#custom-context-fie
 
 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.
 
-![A toggle with the gradual rollout strategy. The toggle is constrained on the custom content field "region" and set to only activate if the region is Africa or Europe.](/img/strategy-constraints.png)
+![A flag with the gradual rollout strategy. The flag is constrained on the custom content field "region" and set to only activate if the region is Africa or Europe.](/img/strategy-constraints.png)
 
 ## Constraint structure
 
@@ -202,15 +202,15 @@ For instance, instead of adding hundreds of user ids to the constraint value lis
 
 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 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.
+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.
 
 ## Incompatibilities and undefined behavior {#incompatibilities}
 
 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 Node.js and Go client SDKs will ignore the new constraints completely: the constraints will not affect the flag's status.
-- The Python client SDK will evaluate the toggle to false, as it cannot evaluate the constraint successfully.
+- The Python client SDK will evaluate the flag to false, as it cannot evaluate the constraint successfully.
 - The .NET, Ruby, and PHP SDKs raise exceptions if the provided operator is not `IN` or `NOT_IN`.
 
 Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks/index.md#strategy-constraints).
@@ -219,6 +219,6 @@ After Unleash 4.9, we updated the [Unleash client specification](https://github.
 
 ## [Deprecated]: Constrain on a specific environment {#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](../reference/environments.md).
+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.md).
 
 [^1]: `userScore` is not a default Unleash field, but can be added as a [custom context field](../reference/unleash-context#custom-context-fields).

website/docs/reference/strategy-variants.md

@@ -79,7 +79,7 @@ If you would like to reassign users to different variants using existing stickin
 
 ### Strategy variants vs feature toggle variants
 
-Strategy variants take precedence over the [feature toggle variants](./feature-toggle-variants.md). If your matching activation strategy doesn't have any variants configured you will fall back to the [feature toggle variants](./feature-toggle-variants.md).
+Strategy variants take precedence over the [feature flag variants](./feature-toggle-variants.md). If your matching activation strategy doesn't have any variants configured you will fall back to the [feature flag variants](./feature-toggle-variants.md).
 Since strategy variants are part of activation strategies they have full access to constraints and segments. Feature variants are much more limited since they only allow simple overrides.
 
 ## How do I configure strategy variants
@@ -90,7 +90,7 @@ In the Unleash UI, you can configure variants by navigating to the gradual strat
 
 ## The `disabled` variant
 
-When your matching strategy has no variants or when your toggle has no variants or when a toggle is disabled for a user, Unleash will return variant data that looks like this:
+When your matching strategy has no variants or when your flag has no variants or when a flag is disabled for a user, Unleash will return variant data that looks like this:
 
 ```json
 {

website/docs/reference/tags.md

@@ -21,6 +21,6 @@ When adding a new tag, a dropdown will show you which type of tag you're about t
 
 Types can be anything, and their purpose is to add some semantics to the tag itself.
 
-Some tag types will be defined by plugins (e.g. the slack plugin can define the Slack-type, to make it easy to specify which Slack channels to post updates for a specific feature toggle to).
+Some tag types will be defined by plugins (e.g. the slack plugin can define the Slack-type, to make it easy to specify which Slack channels to post updates for a specific feature flag to).
 
-Other tags can be defined by the user to give semantic logic to the management of the UI. It could be that you want to use tag functionality to specify which products a feature toggle belongs to, or to which teams.
+Other tags can be defined by the user to give semantic logic to the management of the UI. It could be that you want to use tag functionality to specify which products a feature flag belongs to, or to which teams.