As you develop with feature flags, you'll start to include them from the beginning of your feature development, changing the audience of your features as you go. When this practice is established across your team or organization, you'll want to tie features together and launch them simultaneously as part of a broader release.

The ability to tie gates together is built into Feature Gates. No code changes or development workflow changes are required.

## Launching Features 1 and 2 as part of Release A

Say you're working on Features 1 and 2. An engineer has created Feature Gates for each one: Feature 1 and Feature 2. Each feature is rolled out only to internal stakeholders while implementation is ongoing.

![Feature gate showing internal org members passing while default fails](/images/guides/synchronized-launch/144681310-f63c20fb-0864-432e-9146-faec21fe4971.png)

Later, you decide you want these two features to launch at the same time as part of Release A.

First, create your release gate: Release A. Because you aren't launching yet, leave it returning `false` for everyone.

![Release gate setup with no rules created yet](/images/guides/synchronized-launch/144681358-110f1639-a292-460f-a013-5fc37cfcb500.png)

Next, make Feature 1 and Feature 2 gates depend on Release A by adding a “Passes Target Gate” condition at the top. “Passes target gate” means: if the listed gate passes, also pass for this gate. Set the pass percentage to 100 so that anyone passing the release gate also passes each feature gate. The release gate still fails, so your features remain unavailable to anyone outside your existing gating conditions.

![Feature gate rules showing Passes Target Gate condition ahead of internal org segment](/images/guides/synchronized-launch/144681452-39f9d777-c1d6-475c-b035-0f6eba8f38d6.png)

After you configure both gates, you can continue developing until you're ready to launch.

When you're ready to launch, each of your features depends on the “Release A” gate. Change that gate to pass for the percentage rollout you want.

For example, to roll out to 10% of your user base and check the associated pulse metrics, create an “Everyone, 10%” rollout. The release gate warns you at the top that Feature 1 and Feature 2 depend on it.

![Release gate partial rollout configured to 10 percent and referenced by two gates](/images/guides/synchronized-launch/144681755-fcf60e34-6208-40a6-bcde-ca02cf4935f1.png)

Now, checks in code for Feature Gate A and Feature Gate B pass 10% of the time, and you can measure the combined impact of these changes together in the pulse view for the Release A gate.

### Advanced Rollout with Pulse

To measure the impact of these features independently, add a partial rollout on Feature Gate A, Feature Gate B, and the release gate. This lets you compare Feature 1 vs Control, Feature 2 vs Control, and Feature 1 & 2 vs Control. You can't compare Feature 1 vs Feature 2, and mutual exclusion between Features 1 and 2 isn't enforced. For those comparison types or for mutual exclusivity, go to [Experiments](/experiments/overview).