You can't have "subrows" in Splunk. You can have multivalued fields but they are independent from each other (i.e. you can't sort values in one of them based on order of values in another field). So if that's what you want to do, it won't work that way. Splunk is not Excel 😉
If the order of the events in the table is important to you, you need to provide / create a field with a value that can be sorted to give the order you desire. You can remove this field after the sort if you wish.
@ITWhisperer I think you're talking about other thing that I do.
What I meant was that while Splunk can happily deal with data in form of
|Col1 val1||Col2 val1||Col3 val1||Col4 val1||...|
|Col1 val1||Col2 val2||Col3 val2||Col4 val2||...|
|Col1 val1||Col2 val3||Col3 val3||Col4 val3|
If you have separate rows, even if the value in first column is the same but repeated in several rows, we can handle that easily since each row is separate and you can reorder the results and make sense of it. But if you have it like that:
In this case you have separate columns which contain multivalued fields. Each column is just one aggregate result field. So sorting - for example - column 2 would not change order of column 3.
Splunk has no way of "partially aggregating" separate results while keeping other parts of the result rows separate.
That's what I was talking about. You can process the results like in the first table but then aggregate some rows into a single row to present them like in the second table but it has its caveats.
1) As I said - there is no relation between values in separate rows so you might format them to look like "rows" but they are not rows internally, so you can't - for example - select a set from one "subrow" to pivot to.
2) If your original values contain empty spaces Splunk will be happy to compress them in your results so you might get something like that: