# Ad-hoc data views rationale

**URL:** <https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355>\
**Category:** Kibana\
**Tags:** lens, dashboard, discover, data-views, visualisation\
**Created:** [October 19, 2023, 6:01am UTC](https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355 "2023-10-19T06:01:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tancredi](https://avatars.discourse-cdn.com/v4/letter/t/b3f665/32.png) [@tancredi](https://discuss.elastic.co/u/tancredi)\
**Post date:** [October 19, 2023, 6:01am UTC](https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355/1 "2023-10-19T06:01:56Z")

</div>

I'm not sure about the ad-hoc data views use case. I cannot find any rationale behind it in documentation. For now I have a lot of problems as many of lens/visualisations from integrations are using them, then I cannot change it in one place to include, i.e. remote clusters data there. Wouldn't it be more rational for these ad-hoc views to be based on those persistent ones to be more composable and to have single-point-of-control for base scope selection?  
Maybe I misunderstood something and there is already convenient way to manage those relations. Could someone advise me on this topic?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 16, 2023, 6:02am UTC](https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355/2 "2023-11-16T06:02:24Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

---

<div class="post-metadata">

**Author:** ![drewdaemon](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drewdaemon/32/97779_2.png) [@drewdaemon](https://discuss.elastic.co/u/drewdaemon)\
**Post date:** [November 22, 2023, 6:01pm UTC](https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355/3 "2023-11-22T18:01:24Z")

</div>

Hi @tancredi . Just wanted you to know that the team saw your feedback.

Ad-hoc data views are used in many programmatic scenarios in Kibana (e.g. apps creating hidden data views behind the scenes to power specific embedded visualizations).

However, I think your feedback is targeting the user-created ad-hoc data views in particular.

From that perspective: since the data view menu surfaces all library data views, users were ending up with a lot of clutter, as well being reluctant to create new data views for specific objectives.

The thinking was that users might have use for a temporary data view during data exploration without committing it to the global data view picker.

Another case is that you may have a bespoke visualization that uses specific runtime fields or a special index pattern (for example) without necessarily needing/wanting to reuse that configuration elsewhere.

That said, you aren't the only one who has been interested in some sort of middle ground or at least a smoother relationship between the two types of data views.

Other ideas have included added the ability to promote ad-hoc data views to library data views or the possibility to reuse ad-hoc data views among panels on the same dashboard.

To sum up, I think there's work to do to polish this UX further, but hopefully that gives you some insight into why these exist. Thanks for posting your feedback.

---

<div class="post-metadata">

**Author:** ![drewdaemon](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drewdaemon/32/97779_2.png) [@drewdaemon](https://discuss.elastic.co/u/drewdaemon)\
**Post date:** [November 22, 2023, 6:05pm UTC](https://discuss.elastic.co/t/ad-hoc-data-views-rationale/345355/4 "2023-11-22T18:05:50Z")

</div>