From dda697a748b23d848fbd9d7bca6960d240b18281 Mon Sep 17 00:00:00 2001 From: Adrian Bonilla Date: Fri, 26 Jun 2026 13:35:49 -0700 Subject: [PATCH 1/4] docs: adjust copy of flapgole allowed_features to disallowed_features --- .../application-domains/feature-flags/flagpole.mdx | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx index 883df57e8fde4..0776dd6817e2a 100644 --- a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx +++ b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx @@ -43,7 +43,7 @@ options: ### Owner -`team` +`team` : The name of the team that owns this feature flag @@ -221,16 +221,15 @@ Once the option change is deployed, the feature checks will immediately be activ ## Using Flagpole in single-tenants -To allow your flagpole feature configuration to be used in single-tenant -environments, you'll need to add your feature name to the -`flagpole.allowed_features` list for each tenant. For example, in -`options/regions/acme.yml` add the following: +By default, every Flagpole feature is evaluated in single-tenant environments. You only need to configure a tenant if a feature should never be available there by adding its name to the `flagpole.disallowed_features` denylist. For example, in `options/regions/acme`.yml add the following: ```yaml options: - flagpole.allowed_features: ["organizations:is_sentry"] + flagpole.disallowed_features: ["organizations:is_sentry"] ``` +Features that aren't listed fall through to their normal flagpole.yml configuration. + You can also use the `sentry_singletenant` and `sentry_cell` context values in your feature conditions as required. For example, to roll out a feature to specific cells: From 5f9ae3b1b689516e85bbfc6cd39810d5b6f31eeb Mon Sep 17 00:00:00 2001 From: Adrian Bonilla Date: Fri, 26 Jun 2026 15:12:46 -0700 Subject: [PATCH 2/4] Correctly place backtick --- .../backend/application-domains/feature-flags/flagpole.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx index 0776dd6817e2a..2b3a127b0798c 100644 --- a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx +++ b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx @@ -221,7 +221,7 @@ Once the option change is deployed, the feature checks will immediately be activ ## Using Flagpole in single-tenants -By default, every Flagpole feature is evaluated in single-tenant environments. You only need to configure a tenant if a feature should never be available there by adding its name to the `flagpole.disallowed_features` denylist. For example, in `options/regions/acme`.yml add the following: +By default, every Flagpole feature is evaluated in single-tenant environments. You only need to configure a tenant if a feature should never be available there by adding its name to the `flagpole.disallowed_features` denylist. For example, in `options/regions/acme.yml` add the following: ```yaml options: From 8a6bb6e78e4e2329f044cfda604c9e0fa9e3b026 Mon Sep 17 00:00:00 2001 From: Adrian Bonilla Date: Mon, 29 Jun 2026 13:26:55 -0700 Subject: [PATCH 3/4] Add copy explaining how to exclude features from single_tenant customers --- .../application-domains/feature-flags/flagpole.mdx | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx index 2b3a127b0798c..cb0570b7eb435 100644 --- a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx +++ b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx @@ -228,7 +228,19 @@ options: flagpole.disallowed_features: ["organizations:is_sentry"] ``` -Features that aren't listed fall through to their normal flagpole.yml configuration. +Features that aren't listed fall through to their normal flagpole.yml configuration. To roll a feature everywhere except single-tenant environments, add the following to flagpole.yml: + +feature.organizations:cool-new-feature: + created_at: "2026-06-25" + enabled: true + owner: my-team + segments: + - name: GA + rollout: 100 + conditions: + - operator: equals + property: sentry_singletenant + value: false You can also use the `sentry_singletenant` and `sentry_cell` context values in your feature conditions as required. For example, to roll out a feature to From 0733df57e1ad21241e273b7e08c9de26768567ed Mon Sep 17 00:00:00 2001 From: Adrian Bonilla Date: Mon, 29 Jun 2026 13:29:44 -0700 Subject: [PATCH 4/4] add yaml code fence markers --- .../backend/application-domains/feature-flags/flagpole.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx index cb0570b7eb435..32639a34040f5 100644 --- a/develop-docs/backend/application-domains/feature-flags/flagpole.mdx +++ b/develop-docs/backend/application-domains/feature-flags/flagpole.mdx @@ -230,6 +230,7 @@ options: Features that aren't listed fall through to their normal flagpole.yml configuration. To roll a feature everywhere except single-tenant environments, add the following to flagpole.yml: +```yaml feature.organizations:cool-new-feature: created_at: "2026-06-25" enabled: true @@ -241,6 +242,7 @@ feature.organizations:cool-new-feature: - operator: equals property: sentry_singletenant value: false +``` You can also use the `sentry_singletenant` and `sentry_cell` context values in your feature conditions as required. For example, to roll out a feature to