Hi @satyaallaparthi, Irrespective of the use case--data dictionary, audit artifact, documentation, etc.--see below for a starting point for Simple XML dashboards to run as a user with the admin or sc_admin role. It exposes several problems: 1. Base searches have arbitrary ancestry depth: search -> base1 -> base2 -> base3 -> ... -> baseN You can extended the inner join with additional joins as needed to meet your depth requirements. 2. Base searches may be invalid and require loop detection, although this is moot given problem 1: search -> base1 -> base2 -> base1 (loop) If you extend the inner join, you can track base references and detect loops with creative use of field values and eval logic. 3. Panels may reference prebuilt panels. This was not implemented below, but the logic is similar to the join used to match searches to base searches. The additional logic would match the panel element ref and app attributes to prebuilt panels through another join. 4. Searches may reference saved searches (reports). As above, the additional logic would match the search element ref attribute to saved searches through another join. 5. The mvexpand command has conservative default limits. If you encounter mvexpand errors, see the limits.conf [default] and [mvexpand] stanzas and the max_mem_usage_mb setting for more information. 6. The join command has conservative default limits; however, 50,000 dashboard base search results may meet your requirement. If you have missing or unexpected results, see the limits.conf [join] and [searchresults] stanzas for more information. 7. Not a problem but a warning: Dashboards with the same title (object name) can exist across apps and sharing modes. The search below includes the eai:acl.app, eai:acl.owner, and eai:acl.sharing fields to help differentiate between dashboards. You could also keep the id field as an absolute reference to the object relative to the local search head. 8. The example references the local search head, which should work for standalone search heads, search head clusters, and Splunk Cloud. The logic may not work as-is from a monitoring console with many search head peers and modified splunk_server or splunk_server_group arguments. | rest splunk_server=local /servicesNS/-/-/data/ui/views search="isDashboard=1" search="isVisible=1" search="version!=2" | fields id eai:acl.app eai:acl.owner eai:acl.sharing title label eai:data | rename eai:* as *, acl.* as * | spath input=data "dashboard.row.panel" output=panel | mvexpand panel | spath input=panel "title" output=panel_title | eval panel_title=coalesce(panel_title, "Untitled") | xpath outfield=search "//search" field=panel | mvexpand search | spath input=search "search{@base}" output=base_search_id | spath input=search "search.query" output=search_query | join type=left max=0 id base_search_id [| rest splunk_server=local /servicesNS/-/-/data/ui/views search="isDashboard=1" search="isVisible=1" search="version!=2" | fields id eai:data | xpath outfield=base_search "/dashboard/search" field=eai:data | mvexpand base_search | spath input=base_search "search{@id}" output=base_search_id | spath input=base_search "search.query" output=base_search_query | fields id base_search_id base_search_query ] | eval spl=replace(coalesce(base_search_query." | ".search_query, search_query), "\\|[\\s]*\\|", "|") | table app title owner sharing label panel_title spl Dashboard Studio dashboards have base (chain) search ancestry and saved search problems similar to Simple XML but should be self-contained. The required logic is similar to Simple XML but limited to the visualizations and dataSources objects. A join isn't necessary because there are no XML attribute values to match: | rest splunk_server=local /servicesNS/-/-/data/ui/views search="isDashboard=1" search="isVisible=1" search="version=2" | fields id eai:acl.app eai:acl.owner eai:acl.sharing title label eai:data | rename eai:* as *, acl.* as * | spath input=data "dashboard.definition" output=data | eval panel=json_array_to_mv(json_keys(json_extract(data, "visualizations"))), panel=mvmap(panel, spath(data, "visualizations.".panel)) | mvexpand panel | spath input=panel "title" output=panel_title | eval panel_title=coalesce(panel_title, "Untitled") | spath input=panel "dataSources.primary" output=search_id | eval search_query=spath(data, "dataSources.".search_id.".options.query") | eval base_search_id=spath(data, "dataSources.".search_id.".options.extend") | eval base_search_query=spath(data, "dataSources.".base_search_id.".options.query") | eval spl=replace(coalesce(base_search_query." | ".search_query, search_query), "\\|[\\s]*\\|", "|") | table app title owner sharing label panel_title spl Any edits or additions are welcomed. ... View more

Hi @mfleitma, IPv6 CIDR matching with tstats _should_ work in Splunk Cloud 9.1.2312 and Splunk Enterprise 9.3 or later. Previous versions included this tstats limitation: CIDR matching support for IPv4 and IPv6 addresses The tstats command filters events with CIDR match on fields that contain IPv4 addresses, but not IPv6 addresses. Running tstats searches containing IPv6 addresses might result in the following error indicating that the addresses are treated as non-exact queries: Error in 'TsidxStats': WHERE clause is not an exact query Newer versions include this limitation: Limitations of CIDR matching with tstats As with the search command, you can use the tstats command to filter events with CIDR match on fields that contain IPv4 and IPv6 addresses. However, unlike the search command, the tstats command may not correctly filter strings containing non-numeric wildcard octets. As a result, your searches may return unpredictable results. However, tstats still returns the "exact query" error in Splunk Enterprise 10.0. If your environment is optimized, i.e., you're not using source type renaming or other features that defeat search optimization directives, you may be able to use the datamodel command and achieve performance similar to tstats: | datamodel Intrusion_Detection IDS_Attacks flat summariesonly=true allow_old_summaries=true | search NOT [ | inputlookup ip_test.csv | fields src ] | stats values(sourcetype) as sourcetype count as eventcount max(_time) as maxtime min(_time) as mintime ... View more