Think I was able to get the table in the output you are wanting.  I was able to achieve this using this SPL. | makeresults | eval json_object="{ \"KeyA\": [ { \"path\": \"/attibuteA\", \"op\": \"replace\", \"value\": \"hello\" }, { \"path\": \"/attibuteB\", \"op\": \"replace\", \"value\": \"hi\" } ], \"KeyB\": [ { \"path\": \"/attibuteA\", \"op\": \"replace\", \"value\": \"\" }, { \"path\": \"/attibuteC\", \"op\": \"replace\", \"value\": \"hey\" }, { \"path\": \"/attibuteD\", \"op\": \"replace\", \"value\": \"hello\" } ], \"KeyC\": [ { \"path\": \"/attibuteE\", \"op\": \"replace\", \"value\": \"\" } ] }" | fields - _time | fromjson json_object | fields - json_object ``` Assuming that your fieldset at this point is only the list of fields needed for your final output ``` ``` If there are other fields present that are not apart of the json object you are trying to parse then you should set up a naming convention for fields youy want to loop through ``` | foreach * [ | eval all_objects=mvappend( 'all_objects', case( isnull('<<FIELD>>'), null(), mvcount('<<FIELD>>')==1, json_set('<<FIELD>>', "Key", "<<FIELD>>"), mvcount('<<FIELD>>')>1, mvmap('<<FIELD>>', json_set('<<FIELD>>', "Key", "<<FIELD>>")) ) ) ] | fields + all_objects | mvexpand all_objects | spath input=all_objects | fields - all_objects | fields + Key, path, op, value

I think you should be able to do this by using the mvmap() function. Here is the eval to return the resulting table above. ``` Eval to perform set operation against Splunk multivalue fields ``` | eval new_remove_old_set_operation=case( isnull(new_groups), null(), mvcount(new_groups)==1, if(NOT 'new_groups'=='old_groups', 'new_groups', null()), mvcount(new_groups)>1, mvmap(new_groups, if(NOT 'new_groups'=='old_groups', 'new_groups', null())) )   Full SPL snippet used to replicate your scenario. | makeresults | eval user="user1", old_groups=mvappend( "group1", "group2", "group3" ), new_groups=mvappend( "group1", "group2", "group3", "group4", "group5" ) | append [ | makeresults | eval user="user2", old_groups=mvappend( "group3", "group4", "group5" ), new_groups=mvappend( "group4", "group5", "group6", "group7", "group8" ) ] | fields - _time | fields + user, old_groups, new_groups ``` Eval to perform set operation against Splunk multivalue fields ``` | eval new_remove_old_set_operation=case( isnull(new_groups), null(), mvcount(new_groups)==1, if(NOT 'new_groups'=='old_groups', 'new_groups', null()), mvcount(new_groups)>1, mvmap(new_groups, if(NOT 'new_groups'=='old_groups', 'new_groups', null())) )

So simply hitting the lookup with the input field "Value" as "sFaultInverter1" will pull back ErrorCodes for multiple rows from the lookup since there is multiple "Attribut" values with the same "Value". Since you are asking to pull back ErrorCodes for the "sFaultInverter1" field from the raw data I assume you just want to pull back the ErrorCodes that have the Attribut "sFaultInverter1". This can be done a few different ways. You can scope down the lookup inline to only pull back Attribut="sFaultInverter1" and then do a join against Value from the lookup. That would look something like this. | join type=left sFaultInverter1 [ | inputlookup <lookup> where Attribut="sFaultInverter1" | fields - Attribut | rename Value as sFaultInverter1 ] | fields + "nice_date", sFaultInverter1, ErrorCode Or create a temporary field and include as an additional input field to the lookup like this. | eval scoped_lookup_attribute="sFaultInverter1" | lookup <lookup> Attribut as scoped_lookup_attribute, Value as sFaultInverter1 OUTPUT ErrorCode | fields + "nice_date", sFaultInverter1, ErrorCode  Both of these methods return the same results below You can see that if you only use "sFaultInverter1" as the only input field to the lookup it will actually pull back multiple results since there are multiple Attribut in the lookup with the same Value. They just happen to have the same ErrorCodes in your example, but if they were different that would become problematic. And it would just take more SPL to account for the multivalue field when I don't think it is really needed for this.  

OR is usually placed between predicates in a logical evaluation, e.g. as part of a where command. Splunk works on a pipeline of events and you can't compare between events (without bringing them together in a correlated event). Alerts can be triggered based on expressions, for example, number of events left in the pipeline, so perhaps you need to fashion a search which returns the events you are interested in and trigger on the presence of these events?