[Fleet] Add UI for integration namespace customization by jillguyonnet · Pull Request #269141 · elastic/kibana

jillguyonnet · 2026-05-13T14:53:58Z

Summary

This PR adds the following UI:

Input for managing namespaces enabled for customization for a given package in the package's Settings tab
Toggle for enabling/disabling a namespace for customization when creating/editing a package policy

Note: release notes are included in #262568

Testing

Set up some allowed namespace prefixes for the space, e.g.:

PUT kbn:/api/fleet/space_settings
{
    "allowed_namespace_prefixes": ["prod", "qa"]
}

Integration detail Settings tab
- Pick an integration (e.g. System)
- Check that the "Namespace customization" section is not rendered
- Install the integration
- The "Namespace customization" section should be rendered
- Try to add a namespace that doesn't match the allowed prefixes (e.g. staging): it should be rejected
- Add a namespace that matches the allowed prefixes (e.g. prod1): it should be allowed and a toast notification should confirm
- Check that the namespace was correctly opted in via API (GET /api/fleet/epm/packages/<pkg>, installationInfo.namespace_customization_enabled_for)
- Also test namespace opt out
Package policy editor (create flow)
- Create a package policy (add the integration)
- Open "Advanced options": there should be a toggle labelled "Enable namespace-level customization" that defaults to disabled
- Add a namespace that matches the allowed prefixes and is not already opted in (e.g. prod2), enable the toggle: after saving the policy, this namespace should be added to the list of opted in namespaces for this package
- Create another package policy with the same namespace (prod2), but this time leave the toggle disabled: there should be a warning that doing this will opt out the namespace, affecting the previously created package policy
- Create another package policy with a namespace that is not opted in (e.g. prod3), leave the toggle disabled
- Create another package policy with the same namespace (prod3) and enable the toggle: there should be a warning that doing this will opt in the namespace, affecting the previously created package policy
Package policy editor (edit flow)
- For integration packages, it should be possible to change the namespace and whether it is opted in for the package
- For input packages, the namespace cannot be changed after creation but it should be possible to change whether it is opted in for the package

Screenshots

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Documentation was added for features that require explanation or tutorials
Unit or functional tests were updated or added to match the most common scenarios
If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
Flaky Test Runner was used on any tests changed
The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

See some risk examples
...

infra-vault-gh-plugin-prod · 2026-05-13T15:51:12Z

Pinging @elastic/fleet (Team:Fleet)

jen-huang · 2026-05-13T22:51:17Z

@@ -42,7 +45,7 @@ export function isValidNamespace(
              defaultMessage:
                'Namespace should start with one of these prefixes {allowedNamespacePrefixes}',
              values: {
-                allowedNamespacePrefixes: allowedNamespacePrefixes?.join(', ') ?? '',
+                allowedNamespacePrefixes: allowedNamespacePrefixes.join(', '),


nit: could be collapse into 1 token:

i18n.translate('xpack.fleet.namespaceValidation.notAllowedPrefixError', { defaultMessage: 'Namespace should start with {count, plural, one {{allowedNamespacePrefixes}} other {one of these prefixes: {allowedNamespacePrefixes}}}', values: { count: allowedNamespacePrefixes.length, allowedNamespacePrefixes: allowedNamespacePrefixes.length === 1 ? allowedNamespacePrefixes[0] : allowedNamespacePrefixes.join(', '), }, })

jen-huang · 2026-05-13T22:55:23Z

+    //   Case 3: toggle on  + namespace not yet opted in → opting in may affect others
+    //   Case 8: toggle off + namespace already opted in → opting out may affect others


what's "case 3" and "case 8"? (they are referenced in conditions further in this file too)

Whoops, forgot to clean those up! Thanks for flagging

jen-huang · 2026-05-13T22:56:19Z

@@ -204,6 +221,58 @@ export const StepDefinePackagePolicy: React.FunctionComponent<{
    // Output is also disabled when any parent agent policy is managed (e.g. Elastic Cloud Agent Policy).
    const isOutputDisabled = isManaged || agentPolicies?.some((p) => p.is_managed) === true;

+    // Namespace-level customization toggle visibility/state.
+    const showNamespaceCustomizationToggle =


since we are adding a good amount of state related to namespace customization (plus data fetching), i wonder if all of it could be extracted to a separate hook?

Good point, done 👍

jen-huang · 2026-05-13T23:01:12Z

+            namespaceCustomizationEnabled={namespaceCustomizationEnabled}
+            onNamespaceCustomizationEnabledChange={setNamespaceCustomizationEnabled}
+            installedNamespaceCustomizationEnabledFor={installedNamespaceCustomizationEnabledFor}
+            allowedNamespacePrefixes={spaceSettings?.allowedNamespacePrefixes ?? []}


can we avoid passing 4 new props at this level? can all these be calculated in StepDefinePackagePolicy itself? (might be related to my hook comment earlier)

jen-huang · 2026-05-13T23:02:35Z

+          />
+        </h4>
+      </EuiTitle>
+      <EuiSpacer size="s" />


the spacing here could be tightened up (I think EuiTitle already enforce some bottom margin)

jen-huang · 2026-05-13T23:24:42Z

+      <EuiText size="s" color="subdued">
+        <FormattedMessage
+          id="xpack.fleet.integrations.settings.namespaceCustomization.description"
+          defaultMessage="Opt in namespaces to apply namespace-level customization for this integration. Fleet will create dedicated index templates for each opted-in namespace."


I find the phrasing "namespace-level customization" confusing on this page. @vishaangelova can probably help wordsmith this but here are some ideas:

title: Namespace index templates

input label: Namespaces with dedicated index templates

description: Select which namespaces get a dedicated index template for this integration. This enables independent customization of settings and mappings per namespace. Learn more.

learn more link would go to https://www.elastic.co/docs/reference/fleet/data-streams - we'll need to update the docs here (has a docs issue been filed?)

Hmm, yes, you have a point. I remember I previously approved the "namespace-level customization” wording for the API docs, but I think this is more user-friendly. I’d go with your suggestions, with a tiny tweak for this sentence:

Select which namespaces use a dedicated index template for this integration.

jen-huang · 2026-05-13T23:32:54Z

+                      <EuiText size="xs" color="subdued">
+                        <FormattedMessage
+                          id="xpack.fleet.createPackagePolicy.namespaceCustomization.helpText"
+                          defaultMessage="Allows applying customized settings to all data streams in that namespace."


similar to my other copy sugggestion, maybe something like this:

Creates a dedicated index template for this namespace, enabling independent settings and mappings from other namespaces.

cc @vishaangelova

Not sure I understand this part:

enabling independent settings and mappings from other namespaces.

Might need to think a bit more on the wording here.

jen-huang · 2026-05-14T04:39:37Z

+                          >
+                            <FormattedMessage
+                              id="xpack.fleet.createPackagePolicy.namespaceCustomization.optInImpactDescription"
+                              defaultMessage="Namespace-level customization is shared across all {packageTitle} integration policies targeting namespace {namespace}. Enabling it here will apply to all of them."


related to previous copy suggestion:
The namespace index template is shared across all {packageTitle} policies targeting namespace {namespace}. Enabling it here will apply to all of them.

cc @vishaangelova

To better link the toggle switch and the two sentences, perhaps:

The namespace index template is shared across all {packageTitle} integration policies targeting namespace {namespace}. Enabling the customization here will apply it to all of them.

By "apply it” I mean the namespace index template. Not sure if I’ve understood this correctly. (Do we need to explicitly say “it will apply the template”?)

jen-huang · 2026-05-14T04:40:38Z

+                          >
+                            <FormattedMessage
+                              id="xpack.fleet.createPackagePolicy.namespaceCustomization.optOutImpactDescription"
+                              defaultMessage="Namespace-level customization is shared across all {packageTitle} integration policies targeting namespace {namespace}. Disabling it here will remove it from all of them."


related to previous copy suggestion:
The namespace index template is shared across all {packageTitle} policies targeting namespace {namespace}. Disabling it here will remove it from all of them.

cc @vishaangelova

To better link the toggle switch and the two sentences, perhaps:

The namespace index template is shared across all {packageTitle} integration policies targeting namespace {namespace}. Disabling the customization here will remove it from all of them.

By “remove it” I mean the namespace index template. Not sure if I’ve understood this correctly. (Do we need to explicitly say “will remove the template”?)

vishaangelova · 2026-05-14T13:16:17Z

+      <EuiText size="s" color="subdued">
+        <FormattedMessage
+          id="xpack.fleet.integrations.settings.namespaceCustomization.description"
+          defaultMessage="Opt in namespaces to apply namespace-level customization for this integration. Fleet will create dedicated index templates for each opted-in namespace."


Hmm, yes, you have a point. I remember I previously approved the "namespace-level customization” wording for the API docs, but I think this is more user-friendly. I’d go with your suggestions, with a tiny tweak for this sentence:

Select which namespaces use a dedicated index template for this integration.

vishaangelova · 2026-05-14T13:20:21Z

+                <EuiFlexItem grow={false}>
+                  <FormattedMessage
+                    id="xpack.fleet.integrations.settings.namespaceCustomization.applying"
+                    defaultMessage="Applying namespace customization changes…"


If we use Jen’s wording, maybe this could be Applying namespace index template changes…?

vishaangelova · 2026-05-14T13:45:23Z

+                      <EuiText size="xs" color="subdued">
+                        <FormattedMessage
+                          id="xpack.fleet.createPackagePolicy.namespaceCustomization.helpText"
+                          defaultMessage="Allows applying customized settings to all data streams in that namespace."


Not sure I understand this part:

enabling independent settings and mappings from other namespaces.

Might need to think a bit more on the wording here.

vishaangelova · 2026-05-14T14:05:14Z

+                          >
+                            <FormattedMessage
+                              id="xpack.fleet.createPackagePolicy.namespaceCustomization.optOutImpactDescription"
+                              defaultMessage="Namespace-level customization is shared across all {packageTitle} integration policies targeting namespace {namespace}. Disabling it here will remove it from all of them."


To better link the toggle switch and the two sentences, perhaps:

The namespace index template is shared across all {packageTitle} integration policies targeting namespace {namespace}. Disabling the customization here will remove it from all of them.

By “remove it” I mean the namespace index template. Not sure if I’ve understood this correctly. (Do we need to explicitly say “will remove the template”?)

vishaangelova · 2026-05-14T14:06:46Z

+                          >
+                            <FormattedMessage
+                              id="xpack.fleet.createPackagePolicy.namespaceCustomization.optInImpactDescription"
+                              defaultMessage="Namespace-level customization is shared across all {packageTitle} integration policies targeting namespace {namespace}. Enabling it here will apply to all of them."


To better link the toggle switch and the two sentences, perhaps:

The namespace index template is shared across all {packageTitle} integration policies targeting namespace {namespace}. Enabling the customization here will apply it to all of them.

By "apply it” I mean the namespace index template. Not sure if I’ve understood this correctly. (Do we need to explicitly say “it will apply the template”?)

jillguyonnet · 2026-05-15T14:40:58Z

Thank you @jen-huang and @vishaangelova for your review 🙏

Good point regarding the texts 👍 I pushed some changes, but it might need another round. Comments below to try to keep them centralized.

1. Integration settings:

I really like your suggestion for the help text (also fixed the formatting a bit), added as is.
I still like "Namespace customization" for the section title though, I feel like it conveys the general intent of the feature (that a user would seek). "Namespace index templates" is more precise, but that is already described in the help text. WDYT?
Body of the success notification: I don't have strong feelings about this one, added your suggestion.

2. Package policy editor:

Toggle label: I noticed an inconsistency with the integration settings page: "namespace customization" vs. "namespace-level customization". I prefer the former. Thoughts?
Warning callout when existing package policies may be affected:
- Title: same consideration as above, I like "namespace customization" for consistency
- Body: I like your suggestion, added
Success notification
- Title: left as "Namespace customization updated", let me know if that seems unclear
- Body: updated per your suggestion

3. "Learn more" link: I also thought that would be necessary, but I'm not sure we have a link yet? @vishaangelova maybe let's clarify this directly.

jen-huang · 2026-05-15T20:19:38Z

I still like "Namespace customization" for the section title though, I feel like it conveys the general intent of the feature (that a user would seek). "Namespace index templates" is more precise, but that is already described in the help text. WDYT?

Toggle label: I noticed an inconsistency with the integration settings page: "namespace customization" vs. "namespace-level customization". I prefer the former. Thoughts?

We do not surface the concept of applying settings & mapping at different levels as "customization" anywhere in Fleet. We do already introduce users to the fact that @custom component templates are surfaced at different levels.

My point is that this feature ties in with how Fleet handles templating for integration data streams: we introduce another level, and customization from that point forward is implied.

Namespace customization is vague. To me, it reads as just being able to change the integration's namespace.

"Learn more" link: I also thought that would be necessary, but I'm not sure we have a link yet? @vishaangelova maybe let's clarify this directly.

It should link to https://www.elastic.co/docs/reference/fleet/data-streams which will need to be updated. This is the same docs page that the current Data retention settings info blurb links to:

We still have UX improvement to do on conveying to the user all the levels in which they can customize their data streams, but one step at a time.. 😉

jillguyonnet · 2026-05-18T10:17:12Z

@elasticmachine merge upstream

jillguyonnet · 2026-05-18T10:55:35Z

Thanks Jen for the added context, it makes sense 👍 I've updated the strings per screenshots below, please review.

jillguyonnet · 2026-05-18T11:07:39Z

@vishaangelova FYI I opened elastic/docs-content#6545 to track the documentation change

vishaangelova

Thanks @jillguyonnet! Copy LGTM!

kibanamachine · 2026-05-18T14:47:48Z

💚 Build Succeeded

Buildkite Build
Commit: ade914b

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`fleet`	2141	2145	+4

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`fleet`	2.7MB	2.8MB	+12.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`fleet`	204.7KB	204.8KB	+13.0B

History

💔 Build #443812 failed efa3125
💚 Build #443303 succeeded e75936c
💔 Build #442209 failed b24bda3

cc @jillguyonnet

jen-huang

Thanks for the discussion & changes! LGTM 🚀

[Fleet] Add UI for integration namespace customization

274e369

jillguyonnet self-assigned this May 13, 2026

jillguyonnet added Team:Fleet Team label for Observability Data Collection Fleet team release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting labels May 13, 2026

Handle duplicates

b24bda3

jillguyonnet marked this pull request as ready for review May 13, 2026 15:51

jillguyonnet requested a review from a team as a code owner May 13, 2026 15:51

jen-huang reviewed May 14, 2026

View reviewed changes

vishaangelova reviewed May 14, 2026

View reviewed changes

jillguyonnet added 3 commits May 15, 2026 16:18

Refactor, cleanup and update texts

39e9509

Fix type check

ccedd7e

Merge branch 'main' into fleet/264065-integration-namespace-ui

c80be7e

Fixes

e75936c

jillguyonnet added 2 commits May 18, 2026 12:14

Update strings

1d89e83

Fix input validation UX

902f4a8

elasticmachine and others added 2 commits May 18, 2026 12:17

Merge branch 'main' into fleet/264065-integration-namespace-ui

1a969fa

Add Learn more links

efa3125

jillguyonnet mentioned this pull request May 18, 2026

[Internal]: Document Fleet feature: integration namespace index templates elastic/docs-content#6545

Open

vishaangelova approved these changes May 18, 2026

View reviewed changes

Fix unit test

ade914b

jen-huang self-requested a review May 18, 2026 18:55

jen-huang approved these changes May 18, 2026

View reviewed changes

jillguyonnet merged commit decba43 into elastic:main May 19, 2026
32 checks passed

jillguyonnet deleted the fleet/264065-integration-namespace-ui branch May 19, 2026 07:25

kibanamachine added the v9.5.0 label May 19, 2026

jillguyonnet mentioned this pull request May 19, 2026

[Fleet] Allow users to assign an ILM policy to an Integration #258053

Open

9 tasks

		// Case 3: toggle on + namespace not yet opted in → opting in may affect others
		// Case 8: toggle off + namespace already opted in → opting out may affect others

Conversation

jillguyonnet commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Screenshots

Checklist

Identify risks

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jillguyonnet commented May 15, 2026

Uh oh!

jen-huang commented May 15, 2026

Uh oh!

jillguyonnet commented May 18, 2026

Uh oh!

jillguyonnet commented May 18, 2026

Uh oh!

jillguyonnet commented May 18, 2026

Uh oh!

vishaangelova left a comment

Choose a reason for hiding this comment

Uh oh!

kibanamachine commented May 18, 2026

💚 Build Succeeded

Metrics [docs]

Module Count

Async chunks

Page load bundle

History

Uh oh!

jen-huang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

jillguyonnet commented May 13, 2026 •

edited

Loading