Self-Targeting

Self-targeting lets you serve yourself a specific variation of a feature in any environment, without changing the targeting rules that apply to everyone else. It's the fastest way to QA, debug, or demo a flag in any environment — including production — without writing a one-off rule.

How it works

1. Set your SDK user id, per project. On your profile settings page (/<org>/settings/profile/), the Self-Targeting Identity table lists every project you can see and lets you record the SDK user.id you pass to the evaluation API for that project.
2. Pick an override on the feature page. On any feature's manage page, the Self-Targeting card (under Users & Targeting) shows a row per environment with a "variation" select. Pick a variation and save — the override is yours and yours only.
3. The evaluator does the rest. When the evaluation API receives a request whose user.id matches your SDK id (and the API key is for that project), the override wins over normal targeting rules, and the response carries reason: "self_targeting_override".

Precedence

Self-targeting overrides win over targeting rules but are deliberately ignored when the feature is in a state where targeting itself is meaningless:

Feature state	Override applied?	Reason returned
development / live	Yes	self_targeting_override
complete	No	feature_complete (default served)
archived	No	feature_archived (always off)
Unknown slug	No	variable_not_found (always off)

The dashboard mirrors these rules: the Self-Targeting card hides itself on read-only features so you cannot record an override that would never fire.

Permissions

Self-targeting only affects the dashboard user setting it, so any role (owner, publisher, member, or viewer) may set their own overrides on any feature in any environment they can see — including production. The member-can't-touch-production guard does not apply, because the override is invisible to other users.

Clearing overrides

• Per environment: on the feature's Self-Targeting card, change the select back to — no override — and save.
• Per project (all features at once): on your profile settings page, use the Clear all button on the project row in the Self-Targeting Identity table.

Clearing your project identity (leaving the SDK user id blank) does not delete existing overrides on its own — use the Clear all button if you want to wipe them as well.

Audit log

Every override change is recorded against the feature's audit log:

• self_target_set when an override is created or updated, with the environment, variation, and SDK user id captured in the diff.
• self_target_cleared when an override is removed.

Entries are attributed to the dashboard user who set the override (not the SDK user passed at evaluation time).

When to use it

• Try a flag in production without rolling it out to anyone else.
• Reproduce a customer report by overriding to the same variation the customer is seeing.
• Demo a new variation to a stakeholder without temporary rules.
• Verify your SDK wiring end-to-end — set an override, hit your app, and confirm reason: "self_targeting_override" comes back.

For everything that does not fit those bullet points, prefer real targeting rules so the configuration is discoverable to the rest of your team.