elastic / elastic/docs-content

Rework the data views page intro to explain automatic, manual, and managed data views

Open
#7,502 1 comment 0 reactions 1 assignee Claimed by @florent-leborgne View on GitHub
Team:SKI
Dominant language
No language data
Stars
47
Forks
261
Avg merge
3d 12h
Merged PRs (30d)
116

Description

## Summary

The introduction of the [Data views](https://www.elastic.co/docs/explore-analyze/find-and-organize/data-views) page explains what a data view is, but not how users end up with one. In practice there are three distinct paths, and the intro should set up this mental model up front:

- **Created for you** — some ingest and onboarding workflows create a data view automatically (for example, adding sample data, uploading a file, and some integrations).
- **Created by you** — for your own data you often have to create the data view yourself. Link out to the **Create a data view** section instead of duplicating steps.
- **Managed by Elastic** — some data views are installed and managed by Elastic solutions. These carry a **Managed** tag and are read-only: they can't be edited, and (from 9.4) can't be deleted.

While reworking the intro, reconcile the managed data view explanation so it isn't repeated inconsistently across the page, and review the whole page for accuracy, clarity, and content-type alignment.

**Why this needs docs:** The intro doesn't establish how data views come to exist, and the "managed" concept is currently explained in two places (the Permissions bullet and the *Duplicate managed data views* section intro) with no mention in the intro. Follow-up to #7436 / #7493.

## Scope

### 1. Rework the introduction

- Explain the three creation paths above, kept concise (overview content, not steps).
- Link to **Create a data view** for the manual path rather than duplicating the procedure.
- Introduce managed data views briefly, then point to the authoritative explanation rather than restating the read-only rules.

### 2. De-duplicate the "managed data views" concept

The same "you can view and use these managed data views, but you can't edit them" statement currently appears in:
- the **Permissions** section (`data-views-read-only-access`), now also noting deletion (#7493)
- the **Duplicate managed data views** section intro (`duplicate-managed-data-view`)

Pick one authoritative location for the concept (what a managed data view is + its read-only behavior) and have the intro and the other section reference it, so the rules aren't stated two or three times and can't drift out of sync.

### 3. Whole-page review

- **Accuracy** — verify every UI string, workflow step, and behavior against Kibana at HEAD (labels, the **Actions** column icons, and the delete/duplicate flows).
- **Clarity and flow** — ensure the page still reads coherently after the intro rework; check heading parallelism and TOC scannability.
- **Content-type alignment** — the page mixes overview, how-to (create/delete/manage), and reference (field formatters, runtime vs scripted fields) material. Assess whether the reference-heavy field-formatter and scripted/runtime-field sections are correctly placed, or whether some belongs on a dedicated reference page.
- **Frontmatter/SEO** — the page currently has no meta `description`; add one during the pass.

## Verification notes (codebase-grounded)

- `managed` is a data view property ("Whether the data view is managed by the application", default `false`) in `src/platform/plugins/shared/data_views/common/data_views/abstract_data_views.ts`. Managed data views are created programmatically with `managed: true`, for example:
- Elastic Security default/alert/attack data views (`x-pack/solutions/security/plugins/security_solution/.../initialize_security_data_views`, `create_explore_data_view.ts`).
- Cases analytics data view (`x-pack/platform/plugins/shared/cases/server/cases_analytics_v2/data_view/`).
- The data view management UI renders a **Managed** tag for these (`src/platform/plugins/shared/data_view_management/public/components/utils.ts`).
- Automatic creation on ingest/onboarding is real (sample data sets, file upload, ML data frame analytics `createDataView`, integrations). The implementer should confirm the exact user-facing list of workflows that auto-create a data view before asserting it.

## Resources

- Page: https://www.elastic.co/docs/explore-analyze/find-and-organize/data-views
- Follow-up to: #7436 and #7493 (managed data views can't be deleted)
- Related implementation: elastic/kibana#270608

## Availability

| Channel | Details |
|---------|---------|
| **Stack** | All supported versions (content improvement) |
| **Serverless** | Yes |
| **Feature flag** | None |

---
*Manual follow-up created while working on #7436. Verify all UI strings against Kibana at HEAD before publishing.*

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.