The regular expression that is used to validate the name of the feature flag. Must be a valid regular expression. Flags (such as case insensitivity) are not available.
-
Example (optional)
-
An example of a name that is valid according to the provided pattern. Note: the example must be valid against the described pattern for it to be saved.
-
Description (optional)
-
Any additional text that you would like to display to users to provide extra information. This can be anything that you think they would find useful and can be as long or short as you want.
-
-
-For instance, you might define a pattern that requires all feature flags to follow a specific pattern, such as `^(red|blue|green|yellow)\.[a-z-]+\.[0-9]+$`. You could then provide an example of a valid feature flag name (for instance "blue.water-gun.64") and a description of what the pattern should reflect: "`..`".
diff --git a/website/docs/reference/feature-lifecycle.md b/website/docs/reference/feature-lifecycle.md
deleted file mode 100644
index c1a2a1a021..0000000000
--- a/website/docs/reference/feature-lifecycle.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Feature Lifecycle
----
-
-:::note Availability
-
-**Version**: `6.2+`
-
-:::
-
-![Feature Lifecycle example](/img/feature-lifecycle.png 'Feature Lifecycle example')
-
-In Unleash, the feature lifecycle encompasses a holistic view of how mature your feature is based on data collected through metrics and interactions with the Unleash system.
-As such, the lifecycle mirrors your software development process and allows you to identify bottlenecks at any stage of the lifecycle.
-These findings may give you insights or clues to improve the efficiency of your software development process. Read more about how Unleash progresses a feature through the lifecycle below.
-
-## Lifecycle stages
-
-Each stage in the lifecycle has a defined purpose:
-
-### Initial stage
-
-The feature flag is created but remains unseen in any environment.
-
-**Purpose:** marks the initiation of the feature.
-
-### Pre-live stage
-
-The feature flag has received metrics in non-production environment or has received metrics in a disabled production environment.
-
-**Purpose:** testing and validating the feature before it goes live.
-
-### Live stage
-
-The feature has received metrics in the enabled production environment.
-Once enough has been learned about the feature from production usage, you can mark the feature as completed.
-When marking a feature as complete, you decide whether to keep the feature, discard it, or keep one variant of the feature.
-This information can be used by code cleanup tools to automate feature removal from your code.
-
-**Purpose:** testing and validating the feature in production and marking feature completion.
-
-### Completed stage
-
-The feature's objectives have been achieved, and it is ready to be phased out.
-The lifecycle feature warns you if a completed feature continues to receive traffic, signaling that it hasn't been fully removed from the code.
-If you've accidentally marked the feature as completed, you can always revert it to the live stage.
-
-**Purpose:** initiating cleanup processes and signalling when it's safe to archive a feature.
-
-### Archived stage
-
-The feature is archived in Unleash and can be deleted. If an archived feature is revived, it starts a new lifecycle with a new initial stage.
-
-**Purpose:** reducing technical debt by removing obsolete features.
-
-## Lifecycle stages and process improvement
-
-Understanding how much time a feature spends in each stage can highlight inefficiencies:
-* **Stuck in Initial**: May indicate integration issues in pre-production setups.
-* **Stuck in Pre-live**: Suggests challenges in achieving production readiness.
-* **Stuck in Live**: Could imply difficulties in data gathering or decision-making regarding the feature’s future.
-* **Stuck in Completed**: Indicates delays in decommissioning the feature and cleaning up resources.
diff --git a/website/docs/reference/feature-toggle-types.md b/website/docs/reference/feature-toggle-types.md
deleted file mode 100644
index b7727bd79e..0000000000
--- a/website/docs/reference/feature-toggle-types.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Feature Flag Types
----
-
-:::note Availability
-
-**Version**: `3.5+`
-
-:::
-
-
-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 flag's type affects only two things:
-1. It gives the flag an appropriate icon
-2. The flag's expected lifetime changes
-
-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 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 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 flag's type also helps Unleash understand the [flag's expected lifetime](#expected-lifetimes).
-## Feature flag types
-
-Here's the list of the feature flag types that Unleash supports together with their intended use case and 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 |
-| Operational | Control operational aspects of the system's behavior. | 7 days |
-| Kill switch | Gracefully degrade system functionality. You can read about [kill switch best practices](https://www.getunleash.io/blog/kill-switches-best-practice) on our blog. | Permanent |
-| Permission | Change the features or product experience that certain users receive. | Permanent |
-
-### Expected lifetimes
-
-:::info
-
-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 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 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 flags {#deprecate-a-feature-toggle}
-
-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 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 flag is stale _while_ they're developing.
-- Break a project build if the code contains stale feature flags.
-- Send automatic PRs to remove usage of flags that have served their purpose.
diff --git a/website/docs/reference/feature-toggles.mdx b/website/docs/reference/feature-toggles.mdx
index 4b12e861dd..a3bfe2ae66 100644
--- a/website/docs/reference/feature-toggles.mdx
+++ b/website/docs/reference/feature-toggles.mdx
@@ -2,38 +2,199 @@
title: Feature Flags
---
-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.
+## Overview
-## Configuration options
+Feature flags are a core concept of Unleash. They allow you to release, test, and manage features and functionality across your application without changing the source code.
-Each feature flag has the following configuration options
+Feature flags exist within a [project](./projects) and have distinct configurations and [activation strategies](./activation-strategies) for each of the project's active [environments](./environments). Activation strategies determine whether a feature flag is enabled in a specific environment.
-| Option | Required? | Default value | Description |
-| --- | --- | --- | --- |
-| 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 flag type | Yes | Release | The [feature flag's type](../reference/feature-toggle-types.md). |
-| project | Yes | The [default project](../reference/projects.md). 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 flag's purpose. |
-| enable impression data | Yes | No | Whether to enable [impression data](../reference/impression-data.md) for this flag or not. |
+Feature flags have the following properties:
-## Environments
+- **Name**: A [URL-friendly](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) string between 1 and 100 characters; must be unique per instance.
+- **Type**: The [feature flag's type](#feature-flag-types); defaults to `Release`.
+- **Project**: The [project](./projects) that contains the feature flag.
+- **Description**: An optional description of the feature flag's purpose.
+- **Impression data**: Indicates whether impression data is enabled for the flag; disabled by default.
-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.
+## Environments and activation strategies
-You can enable and disable a flag independently in each of the [project's environments](../reference/projects.md). 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.
+Feature flags have different [activation strategies](./activation-strategies) for each environment, allowing you to manage feature rollouts per environment.
-Refer to the [documentation on environments](../reference/environments.md) for more details on how environments work.
+To activate a feature within an environment, assign at least one activation strategy to it. If you don't specify a strategy, the default is a gradual rollout to 100%.
-## Activation strategies
+Activation strategies determine whether a feature flag activates for a specific [Unleash context](./unleash-context), such as a particular user or segment. When multiple strategies are in place, the flag activates if any one of the strategies evaluates to true.
-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.
+### Strategy variants
-Refer to the [activation strategies documentation](../reference/activation-strategies.md) for a detailed description of all the built-in strategies.
+You can enhance your feature flags with [strategy variants](./strategy-variants.md). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see.
+For example, you might use variants to run an A/B testing experiment.
-## Variants
+Variants are defined by a name and weight, which determines the likelihood of each variant being shown. [Stickiness](./stickiness) ensures that users consistently see the same variant based on predefined parameters.
+Variants can also include payloads such as JSON, CSV, or strings to provide users with additional context.
-[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 flags with payloads
+## Feature flag types
+
+:::note Availability
+
+**Version**: `3.5+`
+
+:::
+
+
+Feature flags have a type to indicate their use case and help you manage and sort your flags. A feature flag's type determines its [expected lifetime](#expected-lifetime) and its visual appearance in the Admin UI.
+
+
+The following is a list of feature flag types:
+
+| Feature flag type | Used to | Expected lifetime |
+|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|
+| Release | Manage the deployment of new or incomplete features. | 40 days |
+| Experiment | Perform multivariate or A/B testing. | 40 days |
+| Operational | Transition between technical implementations with minimal risk. | 7 days |
+| Kill switch | Gracefully degrade system functionality. | Permanent |
+| Permission | Control feature access based on user roles or entitlements. | Permanent |
+
+To learn more, visit [Types of feature flags](../what-is-a-feature-flag#types-of-feature-flags).
+
+## Feature flag state
+
+A feature flag can have one of the following states: _active_, _potentially stale_, or _stale_. Unleash marks all flags as _potentially stale_ automatically once they pass their [expected lifetime](#expected-lifetime).
+
+State gives you an indication of when to [clean up a feature flag in code](./technical-debt.md).
+
+You can also manually change the state on a feature flag's page by going to **Overview** and clicking **Toggle stale state**.
+
+![Marking a feature flag as stale](/img/mark-flag-stale.png)
+
+Marking a flag as stale helps you deprecate a feature flag without removing the active configuration for connected applications.
+
+You can use this to signal to your team to stop using the feature in your applications. Stale flags will show as stale in the [technical debt dashboard](./technical-debt).
+
+Marking a flag as stale generates the `feature-stale-on` [event](./reference/events#feature-stale-on). You can use [an integration](/integrations/integrations) to trigger automated workflows, such as posting notifications in a Slack channel, breaking project builds if the code contains stale flags, or automatically opening pull requests to remove stale flags from the code.
+
+### Configure expected lifetime
+
+Each [feature flag type](#feature-flag-type) has a default expected lifetime.
+With Admin access, you can configure these values. In the Admin UI, go to **Configure > Feature flag types** and edit the flag type you'd like to change.
+
+## Feature flag lifecycle
+
+:::note Availability
+
+**Version**: `6.2+`
+
+:::
+
+Based on usage metrics and interactions with Unleash, feature flags can go through five distinct lifecycle stages: initial, pre-live, live, completed, and archived. These stages mirror the typical software development process and allow you to identify bottlenecks at any stage of the lifecycle.
+These insights can help you improve the efficiency of your software development process.
+
+![Feature lifecycle](/img/feature-lifecycle.png)
+
+### Lifecycle stages
+
+#### Initial
+
+The feature flag is created, but Unleash hasn't detected any metrics in any environments. Once Unleash receives metrics from a non-production environment, the flag moves to the [pre-live](#pre-live) stage.
+
+A feature stuck in an initial stage can indicate integration issues in pre-production setups.
+
+#### Pre-live
+
+The feature flag has received metrics in a non-production environment or a production environment that is disabled. Too much time in the pre-live stage can suggest challenges in achieving production readiness.
+
+#### Live
+
+The first users have been exposed to the feature in a production environment. Once you have enough production usage data, you can mark the feature as completed. Marking the feature flag as complete does not affect any configuration; you decide whether to keep the feature, keep just one variant of it, or archive it entirely.
+
+This stage serves as a reminder to start cleaning up the feature toggle and removing it from the code. A feature flag stuck in the live stage can indicate difficulties in data gathering or decision-making.
+
+#### Completed
+
+The feature has been completed but Unleash still receives usage metrics in production. This is an indication that you should clean up the feature flag from your code before archiving it.
+If you've accidentally marked the feature as completed, you can revert it to the [live](#live) stage.
+
+Too much time in the completed stage can indicate delays in decommissioning the feature and cleaning up resources.
+
+#### Archived
+
+Unleash hasn't detected any production usage metrics for at least two days. It's likely that it is safe to archive this flag.
+If an archived feature is revived, it starts a new lifecycle with a new [initial](#initial) stage.
+
+## Feature flag dependencies
+
+:::note Availability
+
+**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing)
+
+**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) for variants.
+:::
+
+Feature flag dependencies define a relationship between feature flags. Each feature flag can have one parent, but multiple child flags can share the same parent.
+The hierarchy is limited to a single level, meaning a parent flag cannot have its own parent. Additionally, both parent and child flags must belong to the same project.
+
+A child feature flag is evaluated only when both the child and its parent feature are **enabled in the same environment** and the parent dependency value is met. You can set the parent dependency value to one of the following:
+
+- Parent feature is enabled.
+- Parent feature is disabled: Useful when the parent acts as a kill switch with inverted enabled/disabled logic.
+- Parent feature is enabled with variants: Useful for A/B testing scenarios where you need specific variant dependencies.
+
+To add a dependency, you need the `update-feature-dependency` project permission. In the Admin UI, go to the feature flag you want to add a parent to and select **Add parent feature**.
+
+![Feature lifecycle](/img/add-parent-flag.png)
+
+Archiving a child feature flag also removes its dependencies on parent feature flags. A parent feature cannot be archived if it has any child dependencies; in such cases, remove the dependencies, or archive both parent and child together.
+
+Note that metrics are affected only by child feature flag evaluations.
+
+### Variant dependencies
+
+:::note Availability
+
+**Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.12+`
+
+:::
+
+Variant dependencies are satisfied if the parent feature variant is evaluated to the expected value.
+The parent dependency variant is compared to the actual value of the parent in a given environment.
+
+## Set a naming pattern
+
+:::note Availability
+
+**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `5.7+`
+
+:::
+
+A consistent and unique feature flag naming pattern reduces risks and simplifies flag management by preventing the reuse of old names, which could accidentally re-enable outdated features.
+Unique names also make it easier to track and search for flags across codebases, ensuring clarity on what each flag controls and its purpose.
+
+To define a new naming convention for a project, go to **Project settings > Enterprise settings**. For **Naming Pattern**, define a valid [JavaScript regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp).
+Optionally, you can provide an example and a description to guide users when creating new flags.
+
+Once saved, all future feature flag names in the project, including those created via the API, must follow the defined pattern. Note that the full feature flag name must match the pattern; partial matches are not sufficient.
+
+For example, you could set a pattern like `^(red|blue|green)\.[a-z-]+\.[0-9]+$`. You could then provide an example of a valid feature flag name, such as "blue.fast-checkout.64" and a description like: "`..`" to clarify the structure.
+
+## Archive a feature flag
+
+You can archive a feature flag once you no longer need it. To do so, go to the feature flag's page and click **Archive feature flag**.
+
+Once archived, the flag is no longer available to client SDKs.
+
+![Archive a feature flag](/img/archive-feature-flag.png)
+
+### View archived flags
+
+To view an archived feature flag, open the project that contains the flag and select the **Archived flags** tab.
+
+### Revive a feature flag
+
+You can revive archived flags by navigating to the [feature flag archive](#view-archived-flags) and clicking **Revive feature flag**. Revived flags are in an inactive state by default.
+
+### Delete a feature flag
+
+You can delete archived flags by navigating to the [feature flag archive](#view-archived-flags) and clicking **Delete feature flag**.
+
+However, we recommend not deleting feature flags unless they are completely removed from your codebase. If you delete a flag and later create a new one with the same name, it might unintentionally reactivate old code that still references the original flag.
-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.
diff --git a/website/docs/reference/stickiness.md b/website/docs/reference/stickiness.md
index d5edc6bfa4..4b2f091102 100644
--- a/website/docs/reference/stickiness.md
+++ b/website/docs/reference/stickiness.md
@@ -20,7 +20,7 @@ For instance: When using the [gradual rollout activation strategy](../reference/
:::note Availability
-**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) .
+**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table).
:::
diff --git a/website/docs/reference/strategy-variants.md b/website/docs/reference/strategy-variants.md
index 41031c9a73..2ac817a981 100644
--- a/website/docs/reference/strategy-variants.md
+++ b/website/docs/reference/strategy-variants.md
@@ -131,3 +131,8 @@ To make use of strategy variants, you need to use a compatible client. Client SD
If you would like to give feedback on this feature, experience issues or have questions, please feel free to open an issue on [GitHub](https://github.com/Unleash/unleash/).
+
+
+## Environment level variants
+
+[Environment level variants](./feature-toggle-variants) are deprecated. Use strategy variants instead.
\ No newline at end of file
diff --git a/website/docs/reference/technical-debt.md b/website/docs/reference/technical-debt.md
index 7b41b8145d..f6e205fdd2 100644
--- a/website/docs/reference/technical-debt.md
+++ b/website/docs/reference/technical-debt.md
@@ -8,7 +8,7 @@ At Unleash we care deeply about code quality. Technical debt creeps up over time
When a flag is no longer useful, we say that it has become _stale_. A stale flag is a flag that has served its purpose and that you should remove from the code base. For a flag to become stale, you have to explicitly mark it as such. You can mark a flag as stale in the [technical debt dashboard](#the-technical-debt-dashboard).
-Unleash also has a concept of _potentially_ stale flags. These are flags that have lived longer than what Unleash expects them to based on their [feature flag type](../reference/feature-toggle-types.md). However, Unleash can't know for sure whether a flag is actually stale or not, so it's up to you to make the decision on whether to mark it as stale or to keep it as an active flag.
+Unleash also has a concept of _potentially_ stale flags. These are flags that have lived longer than what Unleash expects them to based on their [feature flag type](../reference/feature-toggles#feature-flag-types). However, Unleash can't know for sure whether a flag is actually stale or not, so it's up to you to make the decision on whether to mark it as stale or to keep it as an active flag.
A flag being (potentially) stale, does not affect how it performs in your application; it's only there to make it easier for you to manage your flags.
diff --git a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md
index dba96e1503..09f5e2ceea 100644
--- a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md
+++ b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md
@@ -291,7 +291,7 @@ A good rule of thumb is that if the data is static (you don’t expect it to cha
Feature flag names need to be globally unique. [We wrote about this before](https://docs.getunleash.io/topics/feature-flags/unique-names), but it is such an important point that it bears repeating. Every feature flag within the same Feature Flag Control service must have a unique name across the cluster to prevent inconsistencies and errors.
-In a perfect world, all references to feature flags in code would be cleaned up as soon as the feature flag is archived. But we don’t live in a perfect world. You will save yourself many hours of frustration and potential downtime if you use unique names to protect new features from being accidentally linked to outdated flags, which could inadvertently expose old features. [Unique names should ideally be enforced during flag creation](https://docs.getunleash.io/reference/feature-flag-naming-patterns).
+In a perfect world, all references to feature flags in code would be cleaned up as soon as the feature flag is archived. But we don’t live in a perfect world. You will save yourself many hours of frustration and potential downtime if you use unique names to protect new features from being accidentally linked to outdated flags, which could inadvertently expose old features. [Unique names should ideally be enforced during flag creation](https://docs.getunleash.io/reference/feature-toggles#set-a-naming-pattern).
### 14. Avoid giant feature flag targeting lists.
diff --git a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx
index c4b4a67ff5..ad739aa2b9 100644
--- a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx
+++ b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx
@@ -66,7 +66,7 @@ When connecting an SDK to Unleash, it's the **API key that decides which environ
[**Feature flags**](../reference/feature-toggles.mdx) are at the heart of Unleash’s functionality. Feature flags belong to projects and live next to project environments. In and of itself, a feature flag doesn’t do anything. You must assign [**activation strategies**](../reference/activation-strategies.md) to it for it to start taking effect.
-When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggle-types.md), a [project](../reference/projects.md) it belongs to, and an optional description. Everything except for the name can be changed later.
+When creating a feature flag, you must assign a unique (across your Unleash instance) name, a [feature flag type](../reference/feature-toggles#feature-flag-types), a [project](../reference/projects.md) it belongs to, and an optional description. Everything except for the name can be changed later.