/launchdarkly-flag-targeting

Targeting Safety Checklist

Run through this checklist before applying any targeting changes, especially in production.

Before Every Change

1. Right Environment?

• Confirmed the environment with the user (don't assume "production")
• If the user said "turn it on" without specifying, ask which environment

2. Right Flag?

• Confirmed the flag key matches what the user intends
• If the flag key could be ambiguous, verify with get-flag

3. Understand Current State

• Fetched the flag's current configuration in the target environment
• Noted the current on state, rules, and targets
• Identified any prerequisites that must be met

4. Approval Required?

Some environments require approval for changes.

• If any mutation tool returns requiresApproval: true, inform the user
• Provide the approval URL if one was returned
• Offer to create an approval request with create-approval-request using the returned instructions
• Include a clear description of the intended change in the approval request
• Do NOT attempt to bypass approval or auto-approve
• If checking on a previous request, use list-approval-requests
• Only apply a request (apply-approval-request) if reviewStatus is "approved"

See Approval Workflows for the complete reference.

5. Audit Trail

• Added a comment to the change explaining what and why
• This is especially important for production changes

For Percentage Rollouts

• Weights sum to exactly 100% (100000 in the API)
• The rollout is on the default rule (fallthrough) unless intentionally on a specific rule
• Individual targets and higher-priority rules aren't silently overriding the rollout for some users
• Consider starting small (1-5%) for high-risk features

For Targeting Rules

• New rules are placed at the correct position in evaluation order
• Clauses correctly express the targeting intent (AND within a rule, OR between rules)
• The negate field is set correctly (default false)
• The context kind matches what the codebase sends (e.g., user, device, organization)
• Attribute names match exactly what the SDK sends (case-sensitive)

For Individual Targets

• The values match exactly what the SDK sends as the user/context key
• Individual targets are intended to override rules (they always win)
• Using replaceTargets intentionally: it replaces ALL targets, not just adds

For Cross-Environment Copies

• Source environment is the one you tested in
• Target environment is correct
• You've selected the right included actions (don't accidentally copy ON state to production if you only meant to copy rules)
• Target environment's approval requirements are considered

Production-Specific Checks

For any change to a production environment:

• Change has been tested in a lower environment first (staging, dev)
• Rollback plan is clear (what to do if something goes wrong)
• Comment explains the change for audit trail
• If doing a percentage rollout, start with a small percentage first

After the Change

• Verified the new state with get-flag
• Described the resulting targeting to the user in plain language
• Confirmed the change achieves what the user asked for