# Harness feature flags: create, target, and roll out

## TL;DR
Create your flag in the Harness UI under Feature Flags, add targeting rules per environment, then evaluate it from your app with the Harness SDK. Start with a boolean flag defaulting to off and roll out with percentage or targeted rules. Flags evaluate server-side per target and SDKs pick up changes without a deploy, which is the whole point.

```text
harness feature flags
```

## Steps

1. **Set up a project and environments.** In Harness, go to Feature Flags, create a project, and confirm your environments exist (for example dev and prod).
   Expected: the environments are listed and selectable when you create flags.

2. **Create the flag.** Make a boolean flag (or multivariate if you need more than on/off) and leave the default variation off.
   Expected: the flag appears in the flag list showing its default variation.

3. **Add targeting rules.** Serve the on variation to specific targets, segments, or a percentage rollout. Order matters: specific rules first, default last.
   Expected: the rule summary shows exactly who gets which variation.

4. **Wire up the SDK.** Install the Harness SDK for your language, initialize it with the environment's SDK key from the environment settings, and evaluate the flag for a target in your code.
   Expected: the SDK returns the expected variation for a test target.

5. **Flip it live and verify.** Toggle the flag in the UI and watch your app change behavior without a redeploy.
   Expected: the variation changes within the SDK polling window.

## Use this when
- Doing progressive delivery or percentage rollouts with Harness
- Adding a kill switch to a risky feature
- Running A/B tests backed by Harness flags

## Not for this skill when
- You use an open-source flag tool (Unleash, Flagsmith, OpenFeature self-hosted)
- Migrating flag definitions from LaunchDarkly or Split specifically
- Harness CD pipeline failures (different product surface)
- Writing a custom flag evaluation engine from scratch

## Variant phrasings
- harness ff getting started
- harness split feature flags
- how to use feature flags in harness
- harness flag targeting rules

## Why it happens
Harness Feature Flags evaluates each flag against a target (a user, service, or custom identifier) on the server side, and SDKs poll or stream for updates. That split is why flipping a flag in the UI changes app behavior with no deploy: the decision point is the evaluation call, not the shipped code.

## Edge cases
- SDK keys are per environment. Using the wrong environment's key silently evaluates the wrong rules.
- Flag changes take up to the SDK polling interval to propagate. It is not instant.
- Deleting a flag that code still references falls back to the SDK default. Set a sensible default before you delete.
- The audit log records who flipped what and when. Use it when a rollout surprises you.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst__-IFSuNEPWhvqkWvmd4JoA