> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/feature-management-experimentation/management-and-administration/pipelines.md).
# Pipelines
Learn how to use Harness Feature Management & Experimentation (FME) steps in your Harness pipelines.
Harness Feature Management & Experimentation (FME) adds feature flag steps to [Harness pipelines](https://developer.harness.io/harness-platform/new-to-harness-platform/overview#pipelines), so you can create flags, change targeting, check metrics, and kill a flag in the same auditable workflow as your deployment. The **Pipelines** page in Harness FME lists the pipelines in your [project](/feature-management-experimentation/management-and-administration/projects.md).
***
## Before you begin
Make sure you have the following before you add FME steps to a pipeline:
* **FME pipeline steps enabled:** FME steps are in Limited GA and are enabled per account (`ENABLE_PIPELINES`). Some steps also need their own flag, listed in the banner at the top of this page. Use the banner to request access.
* **An FME project:** Pipelines are created in a [project](/feature-management-experimentation/management-and-administration/projects.md). The **Pipelines** page lists only the pipelines in the current project.
* **A Custom stage:** FME steps run only in a [Custom stage](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/add-a-stage#add-a-custom-stage). They are not available in Deploy, Build, or other stage types.
* **Pipeline permissions:** You need view (`core_pipeline_view`), create/edit (`core_pipeline_edit`), and execute (`core_pipeline_execute`) [pipeline permissions](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control/permissions-reference#pipelines).
* **Feature flag permissions:** You need create/edit (`fme_fmefeatureflag_edit`) [permissions for feature flags](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control/permissions-reference#feature-management-and-experimentation) in every [FME environment](/feature-management-experimentation/management-and-administration/environments.md) the pipeline changes. These are the same permissions you need to edit feature flags in the FME UI.
## Permissions
Pipeline permissions are controlled through [Harness RBAC for FME](/feature-management-experimentation/management-and-administration/permissions/rbac.md). The pipeline does not run with elevated rights. If a step tries to update a flag in an environment where you do not have edit access, that step fails. To get the permissions listed above, an administrator must assign you a role that includes them.
***
## How FME steps work
When you add a step to a Custom stage in the Pipeline Studio, the Step Library includes a **Feature Management & Experimentation** section with FME-specific steps.
Each FME step runs like [any other Harness pipeline step](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/add-a-stage#steps-in-custom-stages) and performs one feature management operation, such as creating a flag, changing its targeting, or killing it. FME steps run in sequence with the rest of the pipeline and support standard pipeline capabilities, including [approvals](https://developer.harness.io/harness-platform/use-harness-platform/approvals/approvals-tutorial), [notifications](https://developer.harness.io/harness-platform/use-harness-platform/notifications-alerts-and-banners/notifications/configure-notifications#configure-pipeline-notifications), and [failure strategies](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps). When an FME step fails, the pipeline follows the failure strategy defined on the step or stage.
## How approvals work with FME steps
An [Approval stage or step](https://developer.harness.io/harness-platform/use-harness-platform/approvals/approvals-tutorial) pauses the pipeline until an approver approves or rejects it. When you run FME steps in a pipeline, Harness approvals control the flow. [FME environment-level approval settings](/feature-management-experimentation/management-and-administration/environments.md#create-environments) **do not** apply to pipeline runs, so add a Harness approval wherever a flag change needs sign-off.
The following diagram shows a typical rollout that gates the full rollout on an approval and kills the flag if an issue is detected:
The reverse direction is also supported. An FME environment can be configured to route its own feature flag and segment change requests through a Harness pipeline, so a change made in the FME UI is gated by the pipeline rather than by individual approvers. Go to [Pipeline-gated changes](/feature-management-experimentation/management-and-administration/pipeline-gated-changes.md).
```mermaid
flowchart LR
A[Create Feature Flag] --> B[Set Individual Targets]
B --> C[Set Default Allocations: 50/50]
C --> D{Harness Approval}
D -- Approved --> E[Set Default Allocations: 100%]
D -- Rejected --> F[Kill Feature Flag]
E --> G{Issue detected?}
G -- Yes --> F
G -- No --> H[Continue pipeline]
```
By adding FME steps to your pipeline stages, you can:
* Create and manage feature flags as part of a deployment or promotion workflow with **Create Feature Flag** and **Update Feature Flag**, including the rollout status, owners, and tags.
* Manage individual targeting lists with **Set Individual Targets** and **Add/Remove Individual Targets**.
* Control the default rollout with **Set Default Allocations**, which sets how traffic is split when no targeting rule applies.
* Gate a rollout on application metrics with **Metric Check**.
* Disable a feature immediately with **Kill Feature Flag** as part of an incident runbook.
***
## Create a pipeline with FME steps
To create a pipeline, select **+ Create a Pipeline**. You can build the pipeline in the UI or import it from a Git repository. Selecting a pipeline opens the Pipeline Studio, where you design it in the **Visual** or **YAML** editor.
{% tabs %}
{% tab title="Visual" %}
The **Visual** tab lets you configure stages and steps in the UI, including [FME steps](#add-fme-steps-to-a-pipeline-stage) in Custom stages. Add a Custom stage and select **Add Step** to open the Step Library.
{% endtab %}
{% tab title="YAML" %}
The **YAML** tab shows the full pipeline definition. Select **Edit YAML** to change the pipeline in code.
{% endtab %}
{% endtabs %}
The two editors stay in sync. A change in the **Visual** editor appears in the YAML, and a change in the YAML appears in the **Visual** editor.
### Create a Harness pipeline
You configure the pipeline like any standard Harness pipeline. The only addition is FME steps inside a Custom stage.
## Add FME steps to a pipeline stage
To add FME steps to a pipeline, do the following:
1. Go to the **Pipelines** page from the FME navigation menu.
2. Select **+ Create a Pipeline**, or select **+Import From Git** to import a pipeline from a Git repository.
3. Enter a name for the pipeline. Optionally, add a description and tags.
4. Select **Inline** to store the pipeline in Harness, or **Remote** to store it in a Git repository.
5. Select **Start**.
6. Select **Add Stage**, then select **Custom Stage**.
7. Select **+ Add Step**. The **Step Library** panel opens on the right.
8. In the **Feature Management & Experimentation (FME)** section, select a step. The table below describes each step.
9. Configure the step in the **Step Parameters** tab.
10. Optionally, configure conditional execution, a failure strategy, or a looping strategy in the **Advanced** tab. Go to [Configure advanced pipeline settings](#configure-advanced-pipeline-settings) for details.
11. Select **Save** to add the step to the stage.
When the stage is complete, select **Save**, then select **Run** to run the pipeline.
The following table lists the FME steps, grouped in the same order as the configuration sections on this page:
| FME step | Use case | When to use it |
| ------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [**Create Feature Flag**](#create-feature-flag) | Create a new feature flag | Use when introducing a new feature flag as part of deployment or feature development. This step creates the flag across all environments with default rollout plans. |
| [**Update Feature Flag**](#update-feature-flag) | Update flag metadata | Use when you need to change the description, rollout status, owners, or tags without changing targeting or limit exposure. |
| [**Delete Feature Flag**](#delete-feature-flag) | Permanently delete a feature flag | Use when a feature flag is no longer needed. Optionally deletes all flag definitions across environments first. |
| [**Archive Feature Flag**](#archive-feature-flag) | Archive a feature flag | Use when a feature flag is no longer active but should be kept for historical reference. |
| [**Kill Feature Flag**](#kill-feature-flag) | Immediately disable a feature | Use to kill the flag in an environment, so it serves the [default treatment](/feature-management-experimentation/use-fme/feature-management/setup/default-treatment.md). |
| [**Restore Feature Flag**](#restore-feature-flag) | Restore a killed feature flag | Use to restore a killed flag in an environment, returning it to its prior serving state. |
| [**Set Default Allocations**](#set-default-allocations) | Control default rollout percentages | Use to set how traffic is split across treatments for users who match no targeting rule (for example, 50/50, 75/25, or 100% on). |
| [**Set Individual Targets**](#set-individual-targets) | Replace the individual targets list | Use to set the complete list of individual targets for a flag in an environment. Replaces any existing list. |
| [**Add/Remove Individual Targets**](#addremove-individual-targets) | Change targeting incrementally | Use to add or remove specific users or segments without overwriting the existing list. |
| [**Set Targeting Rules**](#set-targeting-rules) | Define targeting rules for a feature flag | Use to define or replace the rules that choose a treatment based on segment membership, attributes, or other flag states. |
| [**Limit Exposure**](#limit-exposure) | Control exposure to targeting rules | Use to set the percentage of users exposed to targeting rules in an environment. Everyone else gets the default treatment. |
| [**Reallocate Traffic**](#reallocate-traffic) | Reassign users across treatments | Use to reassign users across treatments without changing the targeting rules. This regenerates the seed used to randomize percentage assignment. |
| [**Set Treatments**](#set-treatments) | Define treatments for a feature flag | Use to define or replace the treatments for a flag in an environment, including the default treatment. |
| [**Set Dynamic Configurations**](#set-dynamic-configurations) | Set dynamic configurations for treatments | Use to attach or update the configuration values returned with each treatment of a flag in an environment. |
| [**Patch Definition**](#patch-definition) | Apply patch operations to a flag definition | Use to apply granular patch operations to a feature flag definition in an environment. |
| [**Definition Instructions**](#definition-instructions) | Apply flag definition instructions atomically | Use to apply structured, UI-driven changes to a feature flag definition in a single atomic operation. |
| [**Set Impression Tracking**](#set-impression-tracking) | Enable or disable impression tracking | Use to control whether impression events are collected for a feature flag. |
| [**Metric Check**](#metric-check) | Evaluate feature flag metrics | Use to check application metrics during a rollout and decide whether the pipeline continues or runs its failure strategy. |
| [**Create Segment**](#create-segment) | Create a segment | Use to create a reusable audience segment for targeting feature flags. |
| [**Update Segment**](#update-segment) | Update segment metadata | Use to change a segment description or owners without changing its targeting logic. |
| [**Delete Segment**](#delete-segment) | Permanently delete a segment | Use when a segment is no longer needed. |
| [**Add/Remove Segment Targets**](#addremove-segment-targets) | Change segment targets incrementally | Use to add or remove target keys from a segment without replacing the whole list. |
| [**Set Rule-Based Segment Targeting**](#set-rule-based-segment-targeting) | Define targeting rules for rule-based segments | Use to define or replace the rules that populate a rule-based segment. |
| [**Create Flagset**](#create-flagset) | Create a flag set | Use to group related feature flags for management and governance. |
| [**Delete Flagset**](#delete-flagset) | Permanently delete a flag set | Use when a flag set is no longer needed. |
| [**Add/Remove Flags from Flagsets**](#addremove-flags-from-flagsets) | Manage flag set membership | Use to add a feature flag to, or remove it from, existing flag sets. |
Example pipeline YAML
The following pipeline uses FME steps in a Custom stage to create a flag, target testers, roll out to 50%, wait for approval, and roll out to everyone. The final **Kill Feature Flag** step runs only if an earlier step in the stage fails, through the `when: stageStatus: Failure` condition.
{% code title="pipeline.yaml" overflow="wrap" %}
```yaml
pipeline:
name:
identifier:
projectIdentifier: Default
orgIdentifier:
tags: {}
variables:
- name: flagName
type: String
description: "The feature flag name for this feature rollout."
required: true
value: <+input>
stages:
- stage:
name: demo_stage
identifier: demo_stage
description: "Custom stage with FME steps for this feature rollout."
type: Custom
spec:
execution:
steps:
- step:
type: FmeFlagCreate
name: initial setup
identifier: initial_setup
spec:
name: <+pipeline.variables.flagName>
trafficType: user
description: live demo flag
- step:
type: FmeFlagSetIndividualTargets
name: add testers to on
identifier: add_testers_to_on
spec:
flagName: <+pipeline.variables.flagName>
environment: Prod-Default
treatments:
- treatment: "on"
keys:
- user1
- user2
segments: []
- step:
type: FmeFlagAddRemoveIndividualTargets
name: add beta user
identifier: add_beta_user
spec:
flagName: <+pipeline.variables.flagName>
environment: Prod-Default
treatments:
- treatment: "on"
addKeys:
- beta_user1
removeKeys: []
addSegments: []
removeSegments: []
- step:
type: Wait
name: Wait_1
identifier: Wait_1
spec:
duration: 10s
- step:
type: FmeFlagDefaultAllocation
name: 50-50 Rollout
identifier: _rollout
spec:
flagName: <+pipeline.variables.flagName>
environment: Prod-Default
allocation:
- treatment: "on"
amount: 50
- treatment: "off"
amount: 50
- step:
type: FmeFlagUpdate
name: Change status to ramping
identifier: FmeFlagUpdate_1
spec:
name: <+pipeline.variables.flagName>
tags:
- demo
rolloutStatus: Ramping
- step:
type: HarnessApproval
name: Harness Manual Approval
identifier: Harness_Manual_Approval
spec:
approvalMessage: Review the change and approve.
includePipelineExecutionHistory: true
isAutoRejectEnabled: false
approvers:
userGroups:
- account._fme_admins
minimumCount: 1
disallowPipelineExecutor: false
approverInputs: []
timeout: 1d
- step:
type: FmeFlagDefaultAllocation
name: Rollout out to everyone
identifier: FmeFlagDefaultAllocation_2
spec:
flagName: <+pipeline.variables.flagName>
environment: Prod-Default
allocation:
- treatment: "on"
amount: 100
- treatment: "off"
amount: 0
- step:
type: FmeFlagKill
name: Kill flag on incident
identifier: kill_flag_on_incident
spec:
flagName: <+pipeline.variables.flagName>
environment: Prod-Default
when:
stageStatus: Failure
tags: {}
```
{% endcode %}
***
## Configure feature flag lifecycle steps
Each FME step is configured in the **Step Parameters** tab after you add it from the Step Library. Every step follows the same pattern: select **+ Add Step** in the stage, select the step under **Feature Management & Experimentation**, fill in the parameters, and select **Apply Changes**.
Any text field accepts a [pipeline variable](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/add-a-variable#define-variables) or expression, such as `<+pipeline.variables.flagName>`, so you can reuse one pipeline for many flags.
### Configure FME steps
The steps in this section create, update, retire, kill, and restore feature flags.
### Create Feature Flag
Use this step to create a feature flag and define it across all environments with default rollout plans.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Create Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Create Feature Flag`).
* **Feature Flag Name**: Add a name for the feature flag or use a pipeline variable (for example, `<+pipeline.variables.FeatureName>`).
* **Traffic Type**: Select the traffic type (for example, `user`).
* **Description**: Optionally, enter a description for the feature flag.
* **Owners**: Optionally, select one or more owners for the feature flag.
* **Tags**: Optionally, add tags to help organize and filter feature flags.
4. Select **Apply Changes** to add the step to the pipeline.
### Update Feature Flag
Use this step to update feature flag metadata without changing rollout behavior or targeting.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Update Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Update Feature Flag`).
* **Feature Flag Name**: Add the name of the existing feature flag.
* **Description**: Optionally, update the feature flag description.
* **Owners**: Optionally, update feature flag ownership.
* **Rollout Status**: Optionally, update the feature flag rollout status.
* **Tags**: Optionally, add or modify tags.
4. Select **Apply Changes** to add the step to the pipeline.
### Delete Feature Flag
Use this step to permanently delete a feature flag. Deletion cannot be undone. Use **Archive Feature Flag** if you might need the flag again.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Delete Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Delete Feature Flag`).
* **Feature Flag Name**: Add the name of the feature flag to delete.
* **Delete All Definitions**: Optionally, enable this option to delete all feature flag definitions across environments before deleting the flag.
4. Select **Apply Changes** to add the step to the pipeline.
### Archive Feature Flag
Use this step to archive a feature flag, keeping it for historical reference without permanently deleting it.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Archive Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Archive Feature Flag`).
* **Feature Flag Name**: Add the name of the feature flag to archive.
4. Select **Apply Changes** to add the step to the pipeline.
### Kill Feature Flag
Use this step to immediately disable a feature flag in a specific environment. A killed flag serves its default treatment to everyone until it is restored.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Kill Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Select **Apply Changes** to add the step to the pipeline.
To kill a flag only when something goes wrong, set a conditional execution on this step in the **Advanced** tab, as shown in the [example pipeline YAML](#add-fme-steps-to-a-pipeline-stage).
### Restore Feature Flag
Use this step to restore a feature flag that was previously killed in a specific environment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Restore Feature Flag** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Select **Apply Changes** to add the step to the pipeline.
***
## Configure targeting and allocation steps
The steps in this section control which users get which treatment in an environment. Steps named **Set** replace the existing configuration. Steps named **Add/Remove** change it incrementally.
### Set Default Allocations
Use this step to control how traffic is allocated across treatments for users who do not match any targeting rule.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Default Allocations** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Under the **Flag Change** section, define one or more allocations by selecting **+ Add Allocation**:
* **Treatment**: Select a treatment to apply.
* **Allocation Percentage**: Enter the percentage of traffic for this treatment (0 to 100).
5. Make sure the allocations across all treatments total 100%.
6. Select **Apply Changes** to add the step to the pipeline.
### Set Individual Targets
Use this step to define the complete set of individual targets for a feature flag in a specific environment. This step replaces any existing individual targets, including keys added earlier by **Add/Remove Individual Targets**.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Individual Targets** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment where targeting should be applied.
* **Feature Flag**: Add the feature flag name.
4. Under the **Set Individual Targets** section, select **+ Add Treatment** for each treatment whose individual targets you want to replace:
* **For Treatment**: Select a treatment to apply.
* **Keys**: Optionally, enter the individual target keys to include.
* **Segments**: Optionally, enter segments to include.
5. Select **Apply Changes** to add the step to the pipeline.
### Add/Remove Individual Targets
Use this step to incrementally add or remove individual targets without replacing the existing target list.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Add/Remove Individual Targets** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the target environment.
* **Feature Flag**: Add the feature flag name.
4. Under the **Flag Change** section, configure one or more treatments by selecting **+ Add Treatment**:
* **For Treatment**: Select a treatment to apply.
* **Add Segments**: Optionally, enter segments to include.
* **Add Keys**: Optionally, enter individual target keys to include.
* **Remove Segments**: Optionally, enter segments to remove.
* **Remove Keys**: Optionally, enter individual keys to remove.
5. Select **Apply Changes** to add the step to the pipeline.
### Set Targeting Rules
Use this step to define or replace the targeting rules for a feature flag in a specific environment. Targeting rules choose which treatment is served based on conditions such as segment membership, user attributes, or other feature flag states.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Targeting Rules** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Under the **Targeting Rules** section, define one or more rules by selecting **+ Add Rule**. Each rule has a condition and an allocation:
* **Condition**: Define one or more conditions. Each condition specifies a matcher type (such as `IN_SEGMENT`, `BOOLEAN`, `EQUAL_NUMBER`, `CONTAINS_STRING`, or `BETWEEN_DATE`), an optional attribute, a value, and an optional negate flag.
* **Allocation**: Define how traffic that matches the condition is split across treatments. Each entry specifies a treatment and a size (0 to 100).
5. Select **Apply Changes** to add the step to the pipeline.
### Limit Exposure
Use this step to set the percentage of users exposed to targeting rules in a specific environment. Everyone else gets the default treatment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Limit Exposure** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
* **Exposure Limit**: Enter the maximum percentage of traffic to expose (0 to 100).
4. Select **Apply Changes** to add the step to the pipeline.
### Reallocate Traffic
Use this step to reassign users across treatments for a feature flag in a specific environment without changing the targeting rules. The step regenerates the seed value that randomizes assignment in percentage distributions, so users can receive a different treatment than before. Avoid running it on a flag with an experiment in progress, because reassigned users invalidate the comparison between treatments.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Reallocate Traffic** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Select **Apply Changes** to add the step to the pipeline.
***
## Configure flag definition steps
The steps in this section change a flag definition in one environment: its treatments, their configurations, or several definition changes at once.
### Set Treatments
Use this step to define or replace the set of treatments for a feature flag in a specific environment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Treatments** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
* **Default Treatment**: Select the treatment to serve by default.
4. Under the **Treatments** section, define two or more treatments by selecting **+ Add Treatment**:
* **Treatment**: Enter the treatment name.
* **Description**: Enter a description for the treatment.
5. Select **Apply Changes** to add the step to the pipeline.
You can add or remove treatments by passing an updated list. A treatment that has traffic allocated to it, through default allocations or targeting rules, cannot be left out. The step fails if a treatment with assigned traffic is missing from the list.
### Set Dynamic Configurations
Use this step to attach or update the dynamic configuration for each treatment of a feature flag in a specific environment. A dynamic configuration is a value, usually JSON, that the SDK returns with the treatment so your code can change behavior without a redeploy.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Dynamic Configurations** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. Under the **Treatments** section, configure one or more treatments by selecting **+ Add Treatment**:
* **Treatment**: Select a treatment.
* **Configuration**: Enter the dynamic configuration value for the treatment.
5. Optionally, define [input variables](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/harness-variables#input-and-output-variables) that this step and later steps can reference.
6. Select **Apply Changes** to add the step to the pipeline.
### Patch Definition
Use this step to apply patch operations to a feature flag definition in a specific environment. It bundles several changes into one operation and suits advanced configurations. Go to the [FME Admin API partial update endpoint](https://docs.split.io/reference/partial-update-feature-flag-definition-in-environment) for the available operations.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Patch Definition** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
* **Operations**: Enter the patch operations to apply to the flag definition.
4. Optionally, define [input variables](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/harness-variables#input-and-output-variables) that this step and later steps can reference.
5. Select **Apply Changes** to add the step to the pipeline.
### Definition Instructions
Use this step to apply structured change instructions to a feature flag definition in a specific environment. All changes are applied atomically: either every change succeeds or none is applied. Use it when you want a UI-driven way to change a flag definition without writing raw patch operations.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Definition Instructions** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Add the feature flag name.
4. In the **Flag Definition Changes** section, select **Add a Flag Change** and select an operation.
5. Add more changes by selecting **+ Add a Flag Change**. Each change type can be used at most once per step.
6. Optionally, in the **Optional Configuration** section, configure treatments for the case where the flag definition does not yet exist in the target environment. These settings are ignored when the flag definition already exists. To configure treatments:
* Select **+ Add Treatment**, enter a treatment name, and optionally enter a description. Repeat for each treatment.
* In the **Default Treatment** field, select a default treatment.
* In the **Baseline Treatment** field, select the treatment that other treatments are compared against.
7. Select **Apply Changes** to add the step to the pipeline.
The following image shows the operations available in step 4:
### Set Impression Tracking
Use this step to enable or disable impression tracking for a feature flag. Impressions record which treatment each user received. Turning them off reduces event volume, but metrics and experiments for the flag stop receiving data.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Impression Tracking** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Specify the feature flag.
* **Impression Tracking**: Enable or disable impression tracking.
4. Select **Apply Changes** to add the step to the pipeline.
***
## Configure Metric Check
The **Metric Check** step is a release monitoring gate. It evaluates metric values for a feature flag against a [JEXL](https://developer.harness.io/harness-platform/use-harness-platform/variables-and-expressions/expression-v2#write-expressions-using-jexl) failure condition. If the condition evaluates to `true`, the step fails and the pipeline follows its failure strategy.
### Metric Check
Metric Check detects early signals during a rollout, such as error rates, latency, or conversion. The values are not tested for statistical significance. Metric Check is a release monitoring feature, not an experimentation feature. Because you choose the lookback window and the threshold, your team can react to early signals and keep deploying quickly.
Each value in a failure condition uses the form `<+metric("METRIC_NAME").treatment("TREATMENT").VARIABLE>`. `METRIC_NAME` is a metric listed in the step's **Metrics** field, `TREATMENT` is a treatment of the flag, and `VARIABLE` is one of the calculations in the following table:
| Variable | Type | Definition | Use case | Example failure condition |
| ---------- | --------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `count` | `long` | Sample size: the number of keys that have any value for the metric during the **Lookback Window** | Detect degradations, set thresholds, measure traffic | `<+metric("Bounce event").treatment("ad-top").count> > 1.3 * <+metric("Bounce event").treatment("off").count>` |
| `sum` | `double?` | Sum of all values across all keys | Enforce budgets or resource limits | `<+metric("usage_tokens").treatment("chatbot").sum> > 1000000` |
| `max` | `double?` | Maximum value across all keys | Enforce budgets or resource limits | `<+metric("prompt_tokens").treatment("on").max> > 5000` |
| `mean` | `double?` | `sum` divided by `count` | Set error rate thresholds, detect performance degradations | `<+metric("Average App Start Time - Split Agents").treatment("on").mean> > 1.1 * <+metric("Average App Start Time - Split Agents").treatment("off").mean>` |
| `min` | `double?` | Minimum value across all keys | Detect performance degradations | `<+metric("API Latency").treatment("on").min> > 0.05` |
| `p50` | `double?` | The middle value of all values across keys | Set latency thresholds, detect performance degradations | `<+metric("Authorization Speed").treatment("high-security").p50> > 0.5` |
| `p95` | `double?` | The value below which 95% of values fall | Set SLAs, latency thresholds, and error rate thresholds | `<+metric("Network Speed").treatment("on").p95> > 500` |
| `p99` | `double?` | The value below which 99% of values fall | Set SLAs, latency thresholds, and error rate thresholds | `<+metric("Compute").treatment("on").p99> > 0.12` |
| `variance` | `double?` | How far the values spread from the average | Measure performance stability and predictability | `<+metric("Streaming Speed").treatment("on").variance> > 0.12` |
Combine conditions with `&&` and `||` to check more than one metric:
```
<+metric("Page Visits").treatment("on").count> > 250 && <+metric("Clicks").treatment("on").count> < 200
<+metric("CLS").treatment("on").mean> > 0.1 || <+metric("INP").treatment("on").mean> > 200
```
You can also compare the same metric across two or more treatments, in addition to setting thresholds:
```
<+metric("Errors").treatment("on").count> > 1.1 * <+metric("Errors").treatment("off").count>
```
To add a Metric Check step to your pipeline, do the following:
1. In your pipeline stage, select **+ Add Step**.
2. Select **Metric Check** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (for example, `Validate Checkout Metrics`).
* **Timeout**: Specify the maximum time the step can wait for metric evaluation to complete before it fails.
* **Environment**: Specify the environment where the feature flag is configured.
* **Feature Flag**: Add the feature flag name.
* **Lookback Window**: Specify the period of metric data to evaluate, counting back from when the step runs (for example, `15m` or `1h`). The step returns an error if there is no data in the lookback window.
* **Metrics**: Enter the name of a metric to evaluate. Use the same metric name in the **Failure Condition** expression. Select **+Add a metric** to enter each additional metric.
4. In the **Failure Condition** field, enter a JEXL expression that evaluates to `true` when the step should fail. For example:
```
<+metric("checkout_error_rate").treatment("on").mean> > 0.05 ||
<+metric("checkout_latency").treatment("on").p95> > 500
```
This condition fails the step if the average checkout error rate exceeds 5%, or if the 95th percentile checkout latency exceeds 500 ms. Here `on` is the treatment being evaluated. Replace it with a treatment name from your feature flag. The step returns an error if the treatment name does not exist.
5. Optionally, configure a [failure strategy](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps) in the **Advanced** tab to define what happens when the check fails, such as rolling back a deployment or stopping the pipeline.
6. Select **Apply Changes** to add the step to the pipeline.
{% hint style="info" %}
**Failure condition**
The failure condition decides when the **Metric Check** step fails. The failure strategy decides what happens next, such as stopping the pipeline or triggering a rollback. Metric Check compares values against the thresholds you set, rather than waiting for statistical significance, which makes it suitable for automated release decisions.
{% endhint %}
After the step runs, you can review the configured inputs, the evaluated metric values, and the pass or fail result in the step execution details view.
The **Details**, **Input**, **Output**, and **Execution Context** tabs show the execution status, the configured inputs, the evaluated metric results, and runtime information.
***
## Configure segment steps
The steps in this section create and maintain segments, which are reusable lists of users or rules that targeting rules can use.
### Create Segment
Use this step to create a standard, large, or rule-based segment for feature flag targeting.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Create Segment** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Create Segment`).
* **Segment Name**: Add a name for the segment.
* **Traffic Type**: Select the traffic type for the segment.
* **Description**: Optionally, enter a description for the segment.
* **Owners**: Optionally, select one or more owners for the segment.
* **Tags**: Optionally, select one or more tags for the segment.
4. Select **Apply Changes** to add the step to the pipeline.
### Update Segment
Use this step to update segment metadata without changing segment targeting behavior.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Update Segment** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Update Segment`).
* **Segment Name**: Add the name of the existing segment.
* **Description**: Optionally, update the segment description.
* **Owners**: Optionally, update segment ownership.
* **Tags**: Optionally, select one or more tags for the segment.
4. Select **Apply Changes** to add the step to the pipeline.
### Delete Segment
Use this step to permanently delete a segment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Delete Segment** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Delete Segment`).
* **Segment Name**: Add the name of the segment to delete.
4. Leave **Delete all segment definitions** selected (the default) to remove the segment definitions in every environment.
5. Select **Apply Changes** to add the step to the pipeline.
### Add/Remove Segment Targets
Use this step to incrementally add or remove target keys from a segment in a specific environment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Add/Remove Segment Targets** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Segment Name**: Add the name of the segment.
* **Environment**: Specify the environment.
* **Add Keys**: Optionally, specify one or more target keys to add to the segment.
* **Remove Keys**: Optionally, specify one or more target keys to remove from the segment.
4. Select **Apply Changes** to add the step to the pipeline.
### Set Rule-Based Segment Targeting
Use this step to define or replace the targeting rules for a rule-based segment.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Set Segment Targeting Rules** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Segment Name**: Add the name of the segment.
* **Environment**: Specify the environment.
4. Under the **Targeting Rules** section, select **+ Add Rule** to add each targeting rule, then configure the following:
* **Exclude Keys**: Optionally, specify one or more target keys to exclude.
* **Exclude Segments**: Optionally, specify one or more segments to exclude.
* **Comment**: Optionally, include a comment.
* **Title**: Optionally, enter a title for the targeting rule.
5. Select **Apply Changes** to add the step to the pipeline.
***
## Configure flag set steps
The steps in this section manage flag sets, which group related feature flags so that SDKs and governance workflows can work with them together.
### Create Flagset
Use this step to create a flag set for organizing related feature flags.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Create Flagset** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Create Flagset`).
* **Flagset Name**: Add a name for the flag set.
* **Description**: Optionally, enter a description for the flag set.
4. Select **Apply Changes** to add the step to the pipeline.
### Delete Flagset
Use this step to permanently delete a flag set.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Delete Flagset** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name (such as `Delete Flagset`).
* **Flagset Name**: Add the name of the flag set to delete.
4. Select **Apply Changes** to add the step to the pipeline.
### Add/Remove Flags from Flagsets
Use this step to add a feature flag to, or remove it from, existing flag sets.
1. In your pipeline stage, select **+ Add Step**.
2. Select **Add/Remove Flags from Flagsets** under **Feature Management & Experimentation** in the Step Library.
3. In the **Step Parameters** tab, configure the following:
* **Name**: Add a step name.
* **Environment**: Specify the environment.
* **Feature Flag**: Specify the feature flag.
* **Add Flag sets**: Specify one or more flag sets to add the feature flag to.
* **Remove Flag sets**: Specify one or more flag sets to remove the feature flag from.
4. Select **Apply Changes** to add the step to the pipeline.
***
## Configure advanced pipeline settings
You can control how an FME step runs or recovers in the **Advanced** tab of each step, and how the whole pipeline behaves in the Pipeline Studio.
## Advanced options
The **Advanced** tab of each step offers the following settings:
* [**Conditional execution**](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/step-skip-condition-settings)**:** Run or skip the step based on pipeline variables, expressions, or runtime inputs. For example, update a flag only in production, or run **Kill Feature Flag** only if an earlier step fails. If both a stage and a step define conditional execution, the **step-level condition takes precedence**.
* [**Failure strategy**](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps)**:** Define what happens when the step fails, such as retrying, rolling back, or stopping the pipeline.
* [**Looping strategy**](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism)**:** Run the step several times, for example once per environment.
To configure settings for the whole pipeline, select **Advanced Options** in the Pipeline Studio sidebar:
{% tabs %}
{% tab title="Pipeline Timeout Settings" %}
Set a [timeout for the entire pipeline](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/pipeline-settings#pipeline-timeout-and-stage-timeout-execution-time-limits). If a run exceeds the configured duration, it fails automatically.
{% endtab %}
{% tab title="Stage Execution Settings" %}
Choose whether to allow selective stage execution. This setting controls whether stages can be run or skipped based on stage-level [execution rules](https://developer.harness.io/continuous-delivery/use-continuous-delivery/cd-building-blocks/executions/step-and-stage-conditional-execution-settings#stage-conditional-execution-settings).
{% endtab %}
{% tab title="Re-run Settings" %}
Control whether inputs can be edited when [re-running a pipeline](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/re-run-with-no-input-changes). If set to **No**, inputs cannot be changed during reruns.
{% endtab %}
{% endtabs %}
### Pipeline notifications
Create [notification rules](https://developer.harness.io/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/notify-users-of-pipeline-events) to notify your team about pipeline events through Slack, Microsoft Teams, email, or PagerDuty.
***
## Troubleshooting
The following issues are the most common causes of a failed FME step.
An FME step fails with a permission error
You need create/edit (`fme_fmefeatureflag_edit`) permission for feature flags in every environment the step changes. The pipeline does not grant extra rights. Ask an administrator to assign a role that includes this permission for the environment. Go to [Harness RBAC for FME](/feature-management-experimentation/management-and-administration/permissions/rbac.md) to review the roles.
Set Treatments fails when you remove a treatment
A treatment that still has traffic allocated to it, through default allocations or targeting rules, cannot be removed. Add a **Set Default Allocations** or **Set Targeting Rules** step before **Set Treatments** to move the traffic off that treatment, then remove it.
Metric Check returns an error instead of passing or failing
The step returns an error when there is no metric data in the **Lookback Window**, or when a treatment name in the failure condition does not exist on the flag. Widen the lookback window, check that the flag is receiving traffic in the selected environment, and check that the metric and treatment names in the expression match the flag exactly.
Set Default Allocations fails validation
The allocation percentages across all treatments must total 100%. Check each **Allocation Percentage** value, including any treatment set to 0.
A flag change ran without the approval configured in the FME environment
FME environment-level approval settings do not apply to pipeline runs. Add a [Harness Approval step](https://developer.harness.io/harness-platform/use-harness-platform/approvals/approvals-tutorial) before the FME step that needs sign-off.
Individual targets added earlier in the pipeline disappeared
**Set Individual Targets** replaces the whole list for the selected treatment, including keys added by an earlier **Add/Remove Individual Targets** step. Use **Add/Remove Individual Targets** for every change after the initial list is set.
***
## Next steps
Go to the following pages to set up the access and governance that FME pipelines rely on:
{% content-ref url="/pages/U0MbpDWGRqKYrH2DwkQU" %}
[Harness RBAC for FME](/feature-management-experimentation/management-and-administration/permissions/rbac.md)
{% endcontent-ref %}
{% content-ref url="/pages/sPqSxCk0cCDbfID9prZg" %}
[Environments](/feature-management-experimentation/management-and-administration/environments.md)
{% endcontent-ref %}
{% content-ref url="/pages/qiHcxHdG4mrpnaeO6NdP" %}
[Policies](/feature-management-experimentation/management-and-administration/policies.md)
{% endcontent-ref %}
{% @harness-feedback/feedback %}