Like your and  livehybrid's solutions.  Just a side note: Dashboard Studio has a known condition where global time range change does not always trigger all panels to refresh. (As acknowledged in Slack.)  I have not traced to the exact condition when this happens, but it probably has something to do with main search-subsearch combinations. ... View more

That was my long-held belief, too.  But SVD-2026-0603 implies that the sidecar is presently utilized by Edge Processor, OpAmp, and SPL2 data pipelines.  I do not see postgres process running even though I'm using default of disabled=false.  I do not use any of these features, so I'm wondering if the process is started only if/only when some of these features are in use. ... View more

How many rows does the search return?  Keep in mind that Dashboard Studio has a 1,000 dropdown limit. (Simple XML's limit is 10,000.) ... View more

I ended up using workarounds for visual effects when needed.  Here is an explanation from the DS team on Slack: "Splunk does use the ISO-8601 normalization, and the T separator is part of the standard, so that transformation itself is expected. The date label is also behaving as expected but I can see why showing the full timestamp could raise confusion."  They ask whether label extraction is the main concern. From my perspective, the problem is forced, implied, and implicit typecasting.  Because time is not a defined data type in SPL, assuming that a string of format nnnn-nn-nn to be a date, nnn-nn-nnTnn:nn:nn to be time (and also nnn-nn-nn nn:nn:nn), then internally transforming its representation is too arbitrary.  Even in the narrow scope of label extraction, my original string is 2026-01-31 19:44:25; the implicit casting interprets this as 2026-01-31T19:44:25+00:00, i.e., in UTC.  Meanwhile, field label rex extracted would have string value of 2026-01-31, yet the implicit casting interprets that as 2026-01-31T08:00:00+00:00, i.e., in Pacific time when server and browser are set to Pacific time.  This shows inconsistence.  Inconsistence can cause even deeper problems. ... View more

As @kml_uvce says, Dashboard Studio does not replicate Simple XML features cleanly.  Here, "cleanly" is the key word.  You did not specify the exact result you are trying to get by setting either $ERRORS$ or $WARNINGS$.  But DS can achieve most effect you want to implement. (I ran into an unexpected bug while testing one use case; I will explain that later.) The most common use case of setting conditional token names is for them to be used on the dashboard itself, mostly to hide or reveal an element as kml_uvce suggests. (Because you cannot use unset token in search, $ERRORS$ and $WARNINGS$ cannot appear in the same panel even in Simple XML.)  So, I constructed this dashboard to demonstrate two methods to achieve such hide-and-seek interaction. { "title": "Drilldown from column chart", "description": "https://community.splunk.com/t5/Dashboards-Visualizations/How-to-Create-a-drill-down-from-a-column-chart/m-p/761714/highlight/true#M59493", "inputs": {}, "defaults": { "dataSources": { "ds.search": { "options": { "queryParameters": { "earliest": "$global_time.earliest$", "latest": "$global_time.latest$" } } }, "ds.spl2": { "options": { "queryParameters": { "earliest": "$global_time.earliest$", "latest": "$global_time.latest$" } } } }, "visualizations": { "global": { "showProgressBar": true } } }, "visualizations": { "viz_FwYm3SJW": { "containerOptions": { "visibility": { "showConditions": [ "condition_brJLKJTd" ] } }, "options": { "markdown": "Only show if *ERROR* is clicked!\n\nDo some search with $ set stuff conditionally:result.error_clicked $ (value is $set stuff conditionally:result.error_clicked$)" }, "type": "splunk.markdown" }, "viz_b4Bxi3gB": { "dataSources": { "primary": "ds_Oaqhxumn" }, "eventHandlers": [ { "options": { "tokens": [ { "key": "name", "token": "click_col" }, { "key": "value", "token": "click_val" }, { "token": "info_clicked_tok", "value": "$set stuff conditionally:result.info_clicked$" } ] }, "type": "drilldown.setToken" } ], "title": "this is your column chart", "type": "splunk.table" }, "viz_o3sdPo7w": { "containerOptions": { "visibility": { "showConditions": [ "condition_5dQcfJWD" ] } }, "options": { "markdown": "This panel only shows if clicked value is **greater than** 0\n\n> clicked name: $click_col$\n\n> clicked value: $click_val$" }, "type": "splunk.markdown" }, "viz_o6JLZxMy": { "dataSources": { "primary": "ds_U44DG9ro" }, "title": "output from >set stuff conditionally<", "type": "splunk.table" }, "viz_xM7oEpU3": { "options": { "markdown": "values in \"set stuff conditionally\" search. Formula is\n`$<search name>.result.<field name>$`\n\n- $ set stuff conditionally:result.info_clicked $: $set stuff conditionally:result.info_clicked$\n- $ set stuff conditionally:result.warn_clicked $: $set stuff conditionally:result.warn_clicked$\n- $ set stuff conditionally:result.warning_clicked $: $set stuff conditionally:result.warning_clicked$\n- $ set stuff conditionally:result.error_clicked $: $set stuff conditionally:result.error_clicked$" }, "type": "splunk.markdown" }, "viz_y668z7ad": { "containerOptions": { "visibility": { "showConditions": [ "condition_6zVp0DS6" ] } }, "options": { "markdown": "Only show if **WARN** is clicked!\n\nDo some search with $ set stuff conditionally:result.warn_clicked $ (value is $set stuff conditionally:result.warn_clicked$)" }, "type": "splunk.markdown" }, "viz_zugP9Nmm": { "containerOptions": { "visibility": { "showConditions": [ "condition_BiyxjNkX" ] } }, "options": { "markdown": "This panel only shows after click\n\nYou last clicked\n\n> Field name (i.e., $ click_col $): $click_col$\n\n> Field value (i.e., $ click_val $): $click_val$" }, "type": "splunk.markdown" } }, "dataSources": { "ds_Oaqhxumn": { "name": "column chart search", "options": { "query": "index=_internal log_level=*\n| chart count over sourcetype by log_level", "queryParameters": { "earliest": "-24h@h", "latest": "now" } }, "type": "ds.search" }, "ds_U44DG9ro": { "name": "set stuff conditionally", "options": { "enableSmartSources": true, "query": "| makeresults format=csv data=\"token_name\ndummy\"\n| eval error_clicked = if(\"$click_col$\" == \"ERROR\", $click_val$, \"iNvAlId\")\n| eval warn_clicked = if(\"$click_col$\" == \"WARN\", $click_val$, \"iNvAlId\")\n| eval warning_clicked = if(\"$click_col$\" == \"WARNING\", $click_val$, \"iNvAlId\")\n| eval info_clicked = if(\"$click_col$\" == \"INFO\", $click_val$, \"iNvAlId\")\n", "queryParameters": { "earliest": "-24h@h", "latest": "now" } }, "type": "ds.search" } }, "layout": { "globalInputs": [], "layoutDefinitions": { "layout_1": { "options": { "height": 960, "width": 1440 }, "structure": [ { "item": "viz_b4Bxi3gB", "position": { "h": 352, "w": 1112, "x": 0, "y": 0 }, "type": "block" }, { "item": "viz_zugP9Nmm", "position": { "h": 176, "w": 328, "x": 1112, "y": 0 }, "type": "block" }, { "item": "viz_o3sdPo7w", "position": { "h": 176, "w": 328, "x": 1112, "y": 176 }, "type": "block" }, { "item": "viz_o6JLZxMy", "position": { "h": 162, "w": 549, "x": 0, "y": 352 }, "type": "block" }, { "item": "viz_xM7oEpU3", "position": { "h": 162, "w": 445, "x": 549, "y": 352 }, "type": "block" }, { "item": "viz_y668z7ad", "position": { "h": 162, "w": 223, "x": 994, "y": 352 }, "type": "block" }, { "item": "viz_FwYm3SJW", "position": { "h": 162, "w": 223, "x": 1217, "y": 352 }, "type": "block" } ], "type": "grid" } }, "options": {}, "tabs": { "items": [ { "label": "New tab", "layoutId": "layout_1" } ] } }, "expressions": { "conditions": { "condition_5dQcfJWD": { "name": "clicked value greater than 0", "value": "$click_val$ > 0" }, "condition_6zVp0DS6": { "name": "WARN clicked", "value": "$set stuff conditionally:result.warn_clicked$ != \"iNvAlId\"" }, "condition_BiyxjNkX": { "name": "a click is performed", "value": "isSet($click_col$)" }, "condition_brJLKJTd": { "name": "ERROR clicked", "value": "$set stuff conditionally:result.error_clicked$ != \"iNvAlId\"" } } } } Upon launch, a "minimal" layout is shown, including one panel with warning about no search result. When you click in column chart, layout will change depending on where you click, e.g., Play with the demo and see if your desired effects can be achieved.  A few pointers. DS provides many visual aids.  This demo dashboard is completely designed in UI, including logical conditions used to hide or show a visual element. (Although some aids may not be available in 9.4; I am using 10.2.)  The demo uses two different mechanisms for interaction.  One is via traditional tokens $click_col$ and $click_val$.  As kml_uvce mentions, they are sufficient for simpler use cases.  The second method is explained next. In DS, building conditional field names, values based on click does not require traditional concept of "token" such as $ERRORS" or "WARNINGS".  This is because DS makes creation, maintenance, and reference to supplemental searches extremely easy.  Once you decide on logic, create a search based on your logic as a standalone data source, check "Access search results or metadata" if you do not use this source in a visual element.  Then, use $<data source name>:result.<field name>$ anywhere a token can be used.  In the demo, these "conditional tokens" are calculated with makeresults; but you can totally create supplemental data sources using index search or any other generating command. (BTW, use of supplemental search/data source is not limited to interacting with clicks; you can totally use them in any way you use a rendered value.)  Although you can technically do the same in Simple XML, it is much, much messier. DS lacks the unset feature for tokens (and search results).  So, some workaround is needed if something depends on them to be unset.  In the demo, I use the value "iNvAlId" to signify unset. (null() assignment does not unset anything.  DS simply retains last set value.) DS allows traditional token value to be set to output of any data source including a supplemental data source. (Traditional token is needed when interacting outside the current dashboard.)  In theory, this achieves calculated token like you can do in Simple XML, only easier to maintain in DS.  But in today's testing, I notice that the (traditional) token value, if set via a secondary data source based on click name/value, is lagging behind by one click.  I consider this a bug. In short, Dashboard Studio can be strong even in complex interactions, as long as you are willing to adapt to its own feature set. (I am keenly aware of the absence of some desirable features in Simple XML, but the set is smaller and smaller.) This is how I see the situation: If you are already proficient in Simple XML, and there are some effects that are harder/impossible to achieve in DS, stay with Simple XML.  Else it is worth venturing into DS even if sometimes that requires a different way to solve the problem.  I have used Simple XML for many years and still have many dashboards there.  But my goto for new dashboard today is Dashboard Studio. ... View more

My problem is I cannot get them tabled together in the same results view. If I try and add P1Sender to This statement confirms @PickleRick and @ITWhisperer 's diagnosis: that field P1Sender only exists in one group of events, let's call them "event type 1", whereas fields Item.RecipientsCount, Item.Recipients{}.Name, Item.Subject are only present in a totally different group of events, let's call them "event type 2". (Most likely they are from two different sourcetypes in index office365.)  The two groups have no overlap.  The implied message they are trying to tell you when they ask you what your data look like is this: Unless you can demonstrate that the two groups have something in common, the result you desire, namely "quick view into emails a user has recently received," is an impossibility. To make this obvious, let me give you two groups of mock events P1Sender [email protected] [email protected] [email protected] and Item.RecipientsCount Item.Recipients{}.Name Item.Subject 2 [email protected] [email protected] You owe me $1,000,000. Where is my money? 1 [email protected] I paid $1,000,000.  Where is my shipment? Can you tell me who receive E-mail from whom? Volunteers in this forum all understand privacy concerns.  We ask what your data look like because we want to help you identify the link between these two groups.  You have two paths forward: Find out which datum/data are in common among the two, and craft a logic to link the two to form a "quick view into emails a user has recently received," or Share format of raw events from the two groups which you believe can help forming a "quick view into emails a user has recently received."  You can use mock events but the format must be the same as your raw events and any redaction must retain enough distinct features to establish possible logical connections between two groups. As you have not realized that the two groups of events have no overlap, let me help you with the second path. Run these two searches separately. index=office365 P1Sender=* ``` event type 1 ``` and index=office365 Item.Recipients{}.Name=*, Item.Subject=* ``` event type 2 ``` Inspect events from each type, find events that can form a "quick view into emails a user has recently received."  Then, anonymize those events to share here. This is some homework you should have done before posting question into a data analytics forum.  These are four golden rules; nay, call them the four commandments: Illustrate data input (in raw text, anonymize as needed), whether they are raw events or output from a search (SPL that volunteers here do not have to look at). Illustrate the desired output from illustrated data. Explain the logic between illustrated data and desired output without SPL. If you also illustrate attempted SPL, illustrate actual output and compare with desired output, explain why they look different to you if that is not painfully obvious. ... View more

@PickleRick nailed the core problem in your case: unclear business logic.  In addition to impossibly large timestamp uncertainty (> 30 second?), "the order of my events can be unpredictable" and "doesnt matter which one comes first, starting or ending" contradict the basic premise of a transaction.  In other words, before you can find a SPL solution, much additional work is needed, e.g., Get timestamp among different data sources to be accurate within 1ms.  This is not a very strict requirement today. Manually review events of interest ("to FAIL", "from FAIL", something of interest in between), and ask tech/business owners how they decide which "pairs" should be flagged.  Arrive at a rule/set of rules that they (owners) can manually perform without exception. After this, you can see if their rules fall within definition of transaction.  IF there indeed is a transaction, you can start with PickleRick's suggestion to test transaction command, then see if some more efficient commands can apply the same rules as @livehybrid suggested.  If not, you will need to workshop with owners to come up with an algorithm before working on SPL. ... View more

Like @livehybrid says, there are different ways to work around such timeouts.  One suggestion about using summary index followed by saved searches: Run the collect before hand as one saved search, not as part of the pipe to run multiple regional searches.  Your regional searches should run against this summary index that you named initial-results. Whether this solves your timeout (or resource) limits will depend on what is hitting such limits in your initial setup.  In your statement, you used "scheduled reports" as plural.  But I cannot relate your mock code to multiple reports.  Could you explain that initial setup, why do you think that the use of dbxlookup is contributing to the problem, and what are the symptoms observed in the initial setup?  What is the expected outcome, whether it is one report broken down by region, or multiple reports (plural), one for each region?  Your mock code also references a lookup named host-regions.csv.  Does this relate to that dbxlookup in your first statement? ... View more

Thank you for providing the context and desired results.  Just note that ContactId, DNIS, and ANI, should not require rex in a "normal" Splunk instance.  I am not certain about ApiLogs; however, I cannot get your rex to work with the mock data you provided.  So, the following assume that all the rex work as you desire. Now, you have this array of JSON objects that have the same keys.  You want each pair of keys to have a different name; but the length of the array is indeterminate.  Here is one of several possibilities provided your instance is 8.1 or above where JSON functions are available. index=XXXX source=XXXX sourcetype=XXXX | rex field=_raw "ContactId=\"(?<ContactId>[^\"]+)\"" | rex field=_raw "DNIS=\"(?<DNIS>[^\"]+)\"" | rex field=_raw "ANI=\"(?<ANI>[^\"]+)\"" | rex field=_raw "ApiLogs=\"(?<ApiLogs>\[.*?\])\"" | eval ApiLogs=replace(ApiLogs, "\\\"", "\"") | spath input=ApiLogs path={} output=api_array | eval api_logs_kv = json_object() | eval idx = mvrange(0, mvcount(api_array)) | foreach idx mode=multivalue [eval element = mvindex(api_array, <<ITEM>>), api_logs_kv = json_set(api_logs_kv, "request_" . '<<ITEM>>', spath(element, "request"), "statusCode_" . '<<ITEM>>', spath(element, "statusCode"))] | fields ContactId ApiLogs api_logs_kv | spath input=api_logs_kv | fields - _* api_logs_kv | table ContactId ApiLogs request_* statusCode_* Your mock data should give ContactId ApiLogs request_0 request_1 request_3 statusCode0 statusCode_1 statusCode_2 <CONTACT_ID> [ {"request":"APINAME1","statusCode":"200"}, {"request":"APINAME2","statusCode":"200"}, {"request":"APINAME3","statusCode":"200"} ] APINAME1 APINAME2 APINAME3 200 200 200 Here, I name the fields with 0-base.  You can always make it 1-base.  Hope this helps. ... View more

Can you rephrase your question by following these four golden rules, nay, four commandments of asking an answerable question? Illustrate data input (in raw text, anonymize as needed), whether they are raw events or output from a search (SPL that volunteers here do not have to look at). Illustrate the desired output from illustrated data. Explain the logic between illustrated data and desired output without SPL. If you also illustrate attempted SPL, illustrate actual output and compare with desired output, explain why they look different to you if that is not painfully obvious. ... View more

Good thing you attempt to illustrate data.  But as several have already pointed out, you need to be precise when discussing data analytics - qualitatively precise.  Not only did you use underscore in one place and dashes in another place as @bowesmana notices, but in this illustration, you give prefix cs in most fields, but sc in the last field.  Is that supposed to be cs-status as opposed to sc-status?  As you change field names, you are asking volunteers here to read you mind about what each field name means in your original post. I think @richgalloway already gives you the solution if you just apply it with the correct field names.  If I have to guess, cs-uri-stem is what you call cs_uri_stem in OP, and cs-status is what you call status in OP.  Hence, <your query for relevant events> | stats count as requests, sum(eval('cs-status'=200)) as success by cs-uri-stem | eval pct=success*100/requests | table cs-uri-stem requests pct ... View more

Could you explain why a value stored in a bit counter would be a sore subject?  I do not know how many bits are in userAccountControl, but if you can tell which bit represents use of smartcard-based auth, you can always calculate whether that bit is modified.  For example, | eval smartCardBit = tonumber(userAccountControl, 16) % pow(2, smartCardBitPos - 1) Here, smartCardBitPos is 1-base from LSB. If your instance is 9.2 or above, there are also a set of Bitwise functions. ... View more

I'm not extracting, just a standard search in spl, the full TEXT field has already been extracted as I said. TEXT=" +MYMSGIDI: An FFDC Incident has been created: \"java.io.IOException: EDC5133I No space left on device.  397\" at ffdc_26.03.15_04.30.06.0.log" This contradicts with your observations that  | search TEXT=*MYMSG* works fine but: | search TEXT=*EDC5133I* doesn't work. As PickeRick indicates, Splunk cannot automatically extract the full field when escaped quotation marks is in between  even though the full field is in fact inside two unescaped quotation marks.  You can test this condition by the following without additional manipulation: | table TEXT You will see "+MYMSGIDI: An FFDC Incident has been created: \" (no quotation mark) which does NOT include the string EDC5133I that you are looking for, but does include MYMSG.  Next, try this | rename TEXT as TEXT_init | rex mode=sed "s/\\\\\"/'/g" | fields - TEXT _kv | extract | table TEXT* You'll see TEXT TEXT_init +MYMSGIDI: An FFDC Incident has been created: 'java.io.IOException: EDC5133I No space left on device. 397' at ffdc_26.03.15_04.30.06.0.log +MYMSGIDI: An FFDC Incident has been created: \ Now, | search TEXT_init=*EDC5133I* will continue to fail but | search TEXT=*EDC5133I* will succeed. ... View more

As the other commenters hinted at, you need to clarify what exactly do you mean by this I'm trying to create an alert based on a field as shown below, I want to search for the EDC5133I text. In richgalloway's reading, you simply want to pick out events with a specific string to generate that alert.  In many cases, searching _raw is probably sufficient.  In PickleRick's reading, you want to search for the string in this field named TEXT.  Like PickleRick said, there is no generic way to do this. If you need to search in that quoted string, one possibility is to replace escaped quotation marks with a different marker.  For example | rex mode=sed "s/\\\\\"/'/g" | fields - TEXT _kv | extract Here is result from emulation TEXT _raw +MYMSGIDI: An FFDC Incident has been created: 'java.io.IOException: EDC5133I No space left on device. 397' at ffdc_26.03.15_04.30.06.0.log blah ... TEXT=" +MYMSGIDI: An FFDC Incident has been created: \"java.io.IOException: EDC5133I No space left on device. 397\" at ffdc_26.03.15_04.30.06.0.log" If the single quotes bothers you, you can also replace them back. Hope this helps. ... View more

Thank you for explaining the dataset and logic.  So, my speculation was not far off.  The difference is that I didn't realize that names var1, var2, etc., are your choice, not field names carried in data. The solution is the same.  Just use the field names in data.  For the three types, you can do index=notable search_name=* [| inputlookup approved_detections.csv] | fillnull value=MISSING action file_name host signature url user | stats count by search_name action file_name host signature url user | stats count Now, there is a chance that the actual field names are very diverse and difficult to maintain in code.  In that case, you may want to maintain that monthly_alert_matrics.csv instead.  If that is the case, you can easily maintain the above code by using this search | inputlookup monthly_alert_metrics.csv | foreach val* [eval everyfield = mvappend(everyfield, <<FIELD>>)] | stats values(everyfield) as everyfield | eval everyfield = mvjoin(everyfield, ",") Then, copy the value of everyfield into the code. ... View more

Let me know if I get this right: the unique combination in each row of monthly_alert_metrics.csv (i.e., not just alert_name) represents an alert type; you want to know how many of such unique combinations are there in a month; however, some rows may not have all val1, val2, val3, val4 populated.  Is this correct? First, if you really, really need to use dedup, know that it has an keepempty option (Optional arguments).  If the above is what you want, this will do: index=notable search_name=* [| inputlookup approved_detections.csv] ``` no need for a second search command ``` | dedup keepempty=true search_name val1 val2 val3 | stats count But dedup often is slower than stats.  You can simply fillnull any missing field. index=notable search_name=* [| inputlookup approved_detections.csv] | fillnull value=MISSING search_name val1 val2 val3 | stats count by search_name val1 val2 val3 | stats count If my interpretation is correct, I cannot find any use of monthly_alert_metrix.csv. Your description stats "whose search_name field is not found within the approved_detections.csv", but your code does the opposite.  If you truly mean "NOT found within" (as opposed to "found within"),  index=notable search_name=* NOT [| inputlookup approved_detections.csv] | fillnull value=MISSING search_name val1 val2 val3 | stats count by search_name val1 val2 val3 | stats count   Bottom line: map is usually not the answer. Hope this helps. ... View more

@yuanliu Hello! because foreach is a "template" command that can handle wildcards (like foreach *), it forces the search engine to switch to Full Materialization. This is so meta😆 In my Slack thread on this subject, madscient used "'all bets are off' mode" to describe such a scenario.  Meanwhile, foreach itself doesn't always degrade performance.  In fact my macro contains another foreach command that does regex and some multivalue calculations.  No degradation.  That's why I speculate that name space manipulation may have triggered foreach to go wild in that thread. I also specifically avoided wildcard with foreach in hope that the compiler will treat the tokens as constant and set rename at compile time.  Obviously that was misguided. Can you try run your search again, but put | fields a b c d (the fields you are renaming) immediately before your macro. This tells Splunk to throw away the extra data before the foreach The reason why I want to preempt potential name collision by adding such rename's is for the macro to stand alone without worrying about side effects.  In my real macro, a b c d are names that wouldn't usually exist in practical dataset. (In other words, the intention is similar to declaring a set of variables as local in some other languages.) Meanwhile, I am also aware of the effect of narrowing field set - again, in relationship to name space manipulation.  A while ago, I posted another Slack thread about tojson command vs json_set() call.  Here was my observation: I did some tests with the same dataset comparable to that used in my original observation. Baseline | stats count tojson | tojson output_field=json field1 field2 field3 | stats count eval | json = json_object("field1", field1, "field2", field2, "field3", field3) | stats count So a | stats count command is used to terminate all three for job inspector. All three would give me event count of 102,365.  Baseline runs for 0.20s, tojson runs for 38.6s, eval runs for 0.26s. ... I suspect that the number of fields carried in raw events may have some effect.  So, I ran | fields field1 field2 field3 | tojson output_field=json field1 field2 field3 | stats count .  In the half-million dataset, run time has reduced to 1.6s.  Still meaningfully longer than eval but the slowdown is much reduced.  Of course, determining which fields might be needed downstream is tedious work and things can change in the future.  So, as a practical measure, I will write the long json_object where I can. (Which fields I will need in a JSON object is much easier to determine; future maintenance is more straightforward.) Knowing that number of fields has effect, I also tested Smart Mode against Fast Mode.  No difference. Is tojson examining every field in a raw event even when a list is provided? (I do understand that syntax allows tojson to be used without list.)  Could this be a potential bug? Basically, my observations in both foreach + rename combo and tojson suggest that whenever a command syntax potentially allows unlimited name tokens, even when actual name tokens are explicitly enumerated, the command goes into that "all bets are off" mode and starts to operate on imaginary list of tokens. ... View more

Meanwhile, Dashboard Studio has built-in drag-and-adjust.  It seems to have some built-in constraint so free-hand adjustment is not completely free.  Then, there is the options.columnformat JSON node where you can manually enter desired width for each column. ... View more

What is the harm? User's dashboards will only be visible by the user. ... View more

Based on the example given, I think the OP wants to adapt dropdowns to actual deployed application and environment combination dynamically.  So, I'd take a different route.  The key is the composition of index names.  I think what you want is like For environment token | tstats count by index | rex field=index "[^_]+_(?<environment>.+)" | stats count by environment | fields - count​ for application token | tstats count by index | rex field=index "(?<application>[^_]+)_" | stats count by application | fields - count​ Here is a complete mockup dashboard: <form version="1.1" theme="light"> <label>multiple dependent dropdown Dashboard</label> <description>https://community.splunk.com/t5/Dashboards-Visualizations/Create-multiple-dependent-dropdown-Dashboard/m-p/758134#M59378</description> <fieldset submitButton="false"> <input type="dropdown" token="environment_tok"> <label>Environment</label> <fieldForLabel>environment</fieldForLabel> <fieldForValue>environment</fieldForValue> <search> <query>| makeresults | eval environment = split("stage,test,prod", ","), application = mvappend("s1", "s2", "s3") | mvexpand environment | mvexpand application | eval index = application . "_" . environment | stats count by index ``` the above emulates | tstats count by index ``` | rex field=index "\S+_(?&lt;environment&gt;.+)" | stats count by environment | fields - count</query> <earliest>-24h@h</earliest> <latest>now</latest> </search> </input> <input type="dropdown" token="application_tok"> <label>Application</label> <fieldForLabel>application</fieldForLabel> <fieldForValue>application</fieldForValue> <search> <query>| makeresults | eval environment = split("stage,test,prod", ","), application = mvappend("s1", "s2", "s3") | mvexpand environment | mvexpand application | eval index = application . "_" . environment | stats count by index ``` the above emulates | tstats count by index ``` | rex field=index "(?&lt;application&gt;[^_]+)_" | stats count by application | fields - count </query> <earliest>-24h@h</earliest> <latest>now</latest> </search> </input> </fieldset> <row> <panel> <title>This is what you put in your search</title> <html> <pre> index="&#36;application_tok&#36;_&#36;environment_tok&#36;" blah, blah </pre> </html> </panel> <panel> <title>This is what your search renders into</title> <html> <pre> index="$application_tok$_$environment_tok$" blah, blah </pre> </html> </panel> </row> <row> <panel> <title>Use this search for environment</title> <html> <pre> | tstats count by index | rex field=index "[^_]+_(?&lt;environment&gt;.+)" | stats count by environment | fields - count </pre> </html> </panel> <panel> <title>Use this search for application</title> <html> <pre> | tstats count by index | rex field=index "(?&lt;application&gt;[^_]+)_" | stats count by application | fields - count </pre> </html> </panel> </row> </form> This way, no matter what combination of deployment is, the dropdowns always have the correct elements.   ... View more

While others have provided technical paths, the big question, in fact an input you should provide for others to answer your question, is what is your general approach to this problem?  Forget Splunk.  Do you have/are you trying to construct a white list? (Not to be used in WAP but for Splunk to use.) Are you trying to construct a black list? (Again, for Splunk to use.)  Some other approach? If you cannot answer this question without Splunk, no amount of Splunk discussion is going to solve the problem. ... View more

As a fun exercise, yes, you can still reuse this users.csv to hunt for duplicate.  Just use lookup command, not inputlookup. (Generally speaking, inputlookup in the middle is not often useful.) And directly count groups instead of trying to hunt for a different group. | inputlookup users.csv WHERE group = "GU" | dedup fname lname init | eval name = lname.", ".fname." ".init | lookup users.csv output group | eval duplicate = if(mvcount(group) > 1, "Yes", "No") | fields name, duplicate You can achieve the final desired output using this technique as well. | inputlookup users.csv WHERE group = "GU" | dedup fname lname init | eval name = lname.", ".fname." ".init | lookup users.csv output group | eval training=if(mvcount(group)>1, "GU/PU", "GU") | table lname fname init training dep phone email Performance-wise, I suspect stats is better. ... View more

This is quite fun learning.  I think @richgalloway has got the most comprehensive.  Maybe a little refinement of search as the interest is probably in CSV files, not KMZ or files that are not lookup files at all. index=_audit isdir=0 size path=*/lookups/*.csv action IN (update created modified add) | stats latest(eval(size/1024/1024)) as size_mb latest(_time) as _time by path Meanwhile, as OP mentioned, search interval can be a challenge if creation-update times spread very widely. I looked into the OP's method.  Whereas inputlookup cannot work directly inside foreach and subsearch, it can be modified to use with map.  The big problem with a search other than in _audit index, however, is that inputlookup can only run within a given app context.  If the lookup returned from the rest command is not visible in this app context, inputlookup will error out.  In addition, unlike _audit index, | rest/servicesNS/-/-/data/lookup-table-files cannot retrieve private lookup files. (This, of course, depends on actual use case.  Maybe you don't want to count private files in.) Nevertheless, here is an example usable in search app: | rest/servicesNS/-/-/data/lookup-table-files | rename "eai:acl.app" as app, "eai:acl.owner" as owner, "eai:acl.sharing" as sharing, "eai:data" as path | table title owner sharing app | search (app = search OR sharing = global) title = *.csv | map maxsearches=100000 search="| inputlookup $title$ | foreach * [| eval b_<<FIELD>>=len('<<FIELD>>') + 1 ] | addtotals b_* fieldname=b | stats sum(b) as b | eval mb=b/1024/1024 | fields mb" | stats sum(mb)   ... View more