The panel will always show when depends token is set. If your search does not use any token defined in <input searchWhenChanged="false"/>, the search will always load, whether the panel is hidden or not. In other words, your requirement cannot be met. There is a really silly token gymnastic to hide a panel before submission. (I don't recommend this.)  That is to use a derivative token as depends; to set this token, a search that depends on submission must be performed.  For example: <form version="1.1" theme="light"> <label>Test searchWhenChanged</label> <description>https://community.splunk.com/t5/Splunk-Search/Panel-loading-without-submit-button/m-p/667821#M229124</description> <init> <set token="loadsummary">go</set> </init> <search> <query> | makeresults | eval fake = "$funcsummaryMQ$" </query> <earliest>$field1.earliest$</earliest> <latest>$field1.latest$</latest> <progress> <condition match="'job.resultCount' != 0"> <set token="show_panel">true</set> </condition> <condition> <unset token="show_panel"></unset> </condition> </progress> </search> <fieldset submitButton="true" autoRun="false"> <input token="field1" type="time" searchWhenChanged="false"> <label>Time Picker</label> <default> <earliest>-15m</earliest> <latest>now</latest> </default> </input> <input type="dropdown" token="subsummary" depends="$loadsummary$" searchWhenChanged="false"> <label>Summary Selection</label> <choice value="FUNC">Function Summary</choice> <choice value="MQ">MQ Summary</choice> <change> <condition value="FUNC"> <set token="funcsummary">true</set> <unset token="funcsummaryMQ"></unset> </condition> <condition value="MQ"> <set token="funcsummaryMQ">true</set> <unset token="funcsummary"></unset> </condition> </change> </input> </fieldset> <row> <panel> <title>Show me funcsummary: $funcsummary$</title> <table> <search> <query>| makeresults | eval funcsummary = "$funcsummary$" </query> <earliest>-24h@h</earliest> <latest>now</latest> </search> <option name="drilldown">none</option> </table> </panel> <panel> <title>Show me funcsummaryMQ: $funcsummaryMQ$</title> <table> <search> <query>| makeresults | eval funcsummaryMQ = "$funcsummaryMQ$"</query> <earliest>-24h@h</earliest> <latest>now</latest> </search> <option name="drilldown">none</option> <option name="refresh.display">progressbar</option> </table> </panel> <panel depends="$show_panel$"> <title>ABC show_panel = $show_panel$</title> <table> <search> <query>index=_internal</query> <earliest>$field1.earliest$</earliest> <latest>$field1.latest$</latest> </search> <option name="count">100</option> <option name="dataOverlayMode">none</option> <option name="drilldown">none</option> <option name="percentagesRow">false</option> <option name="refresh.display">progressbar</option> <option name="rowNumbers">false</option> <option name="wrap">true</option> </table> </panel> </row> </form> As I mentioned above, any hidden search that does not depends on token that requires submission will still be executed.  Only the results will not be visible.

For clarification a reason entry might look like this: Potential Brute-Force Attack: There were [22] failed attempts and [0] successful login(s) observed from origin [0.0.0.0] towards [ABC] over 2 second(s) between 2023-10-10 10:10:10 and 2023-10-10 10:10:12. Rate: ~11 attempts/s. Potential Brute-Force Attack: There were [32] failed attempts and [0] successful login(s) observed from origin [1.1.1.1] towards [ABC] over 2 second(s) between 2023-10-10 11:11:01 and 2023-10-10 11:11:03. Rate: ~13 attempts/s.

Hello, There are several tokens on which already panels are dependent and i believe adding token again for dummy at panel level will again cause issues when other tokes are set.  If you have sample code with Panels with button etc..Will be of great help

I ran the following query, and this appears to work (unless its actually not??)  Your hunch is correct: That search actually does not do what you wanted because dest_ip!=address will always be true. First things first, I assume that lookup1 has MATCH_TYPE=CIDR(ip_address) given that your search has apparent success.  As a side: as @ITWhisperer points out, the ip_address column is already in CIDR notation.  The other column (CIDR) conveys no information for this purpose.  I can't think of any use case where such a column will be useful. CIDR, ip_address 24, 1.2.3.4/24 23, 5.6.7.8/23 I wanted events with source ips that match the ip addresses in the lookup table with destination ips that do not match the ip addresses in the lookup table.  The second half of the statement is imprecise.  Do you mean you want dest_ip that does not match the very IP range that includes src_ip in the exact same event, or do you mean you want dest_ip that does not match any IP range in the lookup table?  If former, use a modified search from @bowesmana's answer: index="index1" | lookup lookup1 ip_address as src_ip OUTPUT ip_address as address | where isnotnull(address) AND cidrmatch(address, dest_ip) If the latter, you can use index="index1" | lookup lookup1 ip_address as src_ip OUTPUT ip_address as src_match | where isnotnull(src_match) | lookup lookup1 ip_address as dest_ip OUTPUT ip_address as dest_match | where isnull(dest_match) But your statement can have a million other interpretations.  Unless you can be specific, none of these will work for you.

HI ITWhisperer, I have used the statement you gave and it works well and have used it to get the gap between the days as i wish to use this in an average |eval reltimeearl = if(isnum(1698796800),1698796800,relative_time(now(),"1698796800")) |eval reltimelate = if(isnum(1699056000),1699056000,if("1699056000"=="now",now(),relative_time(now(),"1699056000"))) | where sTime>reltimeearl AND sTime<=reltimelate |eval relgap=(tonumber(reltimelate-reltimeearl)/86400) | stats sum(Percentage_Rec) as Rec1 by description key | eval Av_Rec=(Rec1/relgap) | table description Rec1    This does not work as the relgap is not processed. Looking at the fields when in Verbose mode - i can see a count against this value. As a test i did dedup relgap so the count=1. However this still does not pass to the eval statement. Can you see why?  just using a value of 3 works...   eval Av_Rec=(Rec1/3)

You could try something like this (untested): Include a dummy eval in all your panel searches | eval _dummy=$dummy$ | fields - _dummy Then, when your refresh button is pressed, assign a new value to the token, perhaps something like this: <eval token="dummy">time()</eval>  The idea being that the searches will rerun when there is a change.

the problem is the moment i select any of the value from drop down dependent panels load without waiting for Submit button. This is not accurate.  In fact, the panel appears the moment any value is selected.  This is expected.  But any search that depends on an input requiring submit will not execute until you submit. You can observe this using the following play dashboard:     <form version="1.1" theme="light"> <label>Test searchWhenChanged</label> <description>https://community.splunk.com/t5/Splunk-Search/Panel-loading-without-submit-button/m-p/667821#M229124</description> <init> <set token="loadsummary">go</set> </init> <fieldset submitButton="true" autoRun="false"> <input token="field1" type="time" searchWhenChanged="false"> <label>Time Picker</label> <default> <earliest>-15m</earliest> <latest>now</latest> </default> </input> <input type="dropdown" token="subsummary" depends="$loadsummary$" searchWhenChanged="false"> <label>Summary Selection</label> <choice value="FUNC">Function Summary</choice> <choice value="MQ">MQ Summary</choice> <change> <condition value="FUNC"> <set token="funcsummary">true</set> <unset token="funcsummaryMQ"></unset> </condition> <condition value="MQ"> <set token="funcsummaryMQ">true</set> <unset token="funcsummary"></unset> </condition> </change> </input> </fieldset> <row> <panel> <title>Show me funcsummary: $funcsummary$</title> <table> <search> <query>| makeresults | eval funcsummary = "$funcsummary$" </query> <earliest>-24h@h</earliest> <latest>now</latest> </search> <option name="drilldown">none</option> </table> </panel> <panel> <title>Show me funcsummaryMQ: $funcsummaryMQ$</title> <table> <search> <query>| makeresults | eval funcsummaryMQ = "$funcsummaryMQ$"</query> <earliest>-24h@h</earliest> <latest>now</latest> </search> <option name="drilldown">none</option> <option name="refresh.display">progressbar</option> </table> </panel> <panel depends="$funcsummaryMQ$"> <title>ABC</title> <table> <search> <query>index=_internal</query> <earliest>$field1.earliest$</earliest> <latest>$field1.latest$</latest> </search> <option name="count">100</option> <option name="dataOverlayMode">none</option> <option name="drilldown">none</option> <option name="percentagesRow">false</option> <option name="refresh.display">progressbar</option> <option name="rowNumbers">false</option> <option name="wrap">true</option> </table> </panel> </row> </form>     The above is true unless a search doesn't even use any input that requires submit - as is the case with your sample panel.  Logically submit must not affect any such search. The attribute searchWhenChanged in an <input/> only controls <search/>, and is only useful when a particular <search/> utilizes that specific <input searchWhenChanged="false"/>.  It has no effect on <row/> and <panel/>'s depends attribute.  

In that case, you select only those results with non-null value in fields unique to index=*-palo.  Based on your original sample code, dest_ip is the field that all three sources need to match, but threat and "Palo Detected User" in the end result only come from index=*-palo search.  Therefore, (index=*-palo threat="SMB: User Password Brute Force Attempt(40004)" src=* dest_port=445) OR (index=*-sep device_ip=*) OR (index="*wineventlog" src_ip=*) | eval dest_ip=coalesce(dest, device_ip, src_ip) | eval "Palo Detected User" = if(match(index, "-palo"), user, null()) | rename user as username | fields future_use3 src_ip dest_ip dest_port "Palo Detected User" device_name user_name rule threat repeat_count action ComputerName username | stats values(*) as * by dest_ip threat "Palo Detected User" | sort src_ip | rename future_use3 AS "Date/Time" src_ip AS "Source IP" dest_ip AS "Destination IP" user_name AS "Symantec Detected User @ Destination" device_name AS "Symantec Destination Node" rule AS "Firewall Rule" threat as "Threat Detected" action as "Action" repeat_count AS "Repeated Times" Technically, you can filter based on previous results.  But Splunk's groupby clause only tabulates non-null values.  So, this is cheaper than getting all 10000 stats before filtering.