From dda697a748b23d848fbd9d7bca6960d240b18281 Mon Sep 17 00:00:00 2001 From: Adrian Bonilla Date: Fri, 26 Jun 2026 13:35:49 -0700 Subject: [PATCH 1/2] 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/2] 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: