> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Build whitelists to roll out a feature to internal users
> Use visitor code whitelists and targeted delivery rules to QA feature experiments with specific internal users before a broader release.
If you want to QA a feature experiment or roll out a feature variation to an internal group of users, you can combine a user whitelist with a targeted delivery rule. This combination is one of the easiest ways to do it.
For example, suppose you want to release a new feature with two variations: Feature A and Feature B. Before launching the experiment, you want to QA its live behavior by showing Feature A to a group of internal users and Feature B to a group of stakeholders. Follow these steps to set up that QA test:
1. Create segments of whitelisted users (Group A and Group B).
2. Create a targeted delivery rule for each group of users.
Avoid setting many user IDs (fewer than 20 per variation): the size of your data file increases, and so does the latency, since the SDK must fetch a larger file. If you want to target more users, you can set a custom data attribute for the whole audience (for example, internal users only), then target the experience with that audience.
## Create a targeted delivery rule for each group of users
1. Click **Activate** > **Feature flags** and edit your feature flag.
2. Add a new rule and select **Targeted delivery**.
3. On the right side of the panel, create a new segment (Group A) and look for the **Visitor code** condition. Add the user IDs that you want to be part of Group A.
4. Choose the variation you want to serve, for example, Variation A. All users from Group A receive Variation A of your flag.
5. Add a second **Targeted delivery** rule and replicate the steps for Variation B and Group B.