Extract all Values from nested Association
Given
asso = <|a -> tr, b -> <|c -> <|d -> 12, e -> del|>|>, f -> g|>
then directly
Level[asso, {-1}]
{tr, 12, del, g}
See this post where you can find clear illustrations of "how work levels".
ass = <|a -> tr, b -> <|c -> <|d -> 12, e -> del|>|>, f -> g|>
Those are mirrored answers from How to switch from List of rules to Association?
ass //. a_Association :> Values[a] // Flatten
or
Flatten @ Replace[ass, a_Association :> Values[a], {0, Infinity}]
{tr, 12, del, g}
I'm just adding this answer because of your other question which I think is strongly related to this one and only when seeing both questions together it becomes clear you are not using the JSON data of the other question correctly. It probably is worth noting that Associations
do AFAIK respect the order of fields, so answering this question on its own seems reasonable, especially when making the assumption that you control how the data is generated. I still wouldn't suggest to ignore the actual keys even in that case because keys usually are there for a reason and using them creates code which is much cleaner and more robust, but that is a different subject.
But as the original data comes from an imported JSON string which is generated from code not under your control I think it is plain wrong (or at least asking for trouble) to extract the data without actually looking at the keys. Here is what I would do for your example:
data = <|a -> tr1, b -> <|c -> <|d -> 12, e -> del|>|>, f -> g|>
data @@@ {{a}, {b, c, d}, {b, c, e}, {f}}
or, if generalized to a list of such associations (which I think is what you'll ultimately have to do for the data in your other question):
data = {
<|a -> tr1, b -> <|c -> <|d -> 12, e -> del|>|>, f -> g|>,
<|a -> tr2, b -> <|c -> <|e -> del|>|>, f -> h|>,
<|a -> tr3, b -> <|c -> <|e -> del, ee-> 5, d -> 14|>|>, f -> i|>
};
(# @@@ {{a}, {b, c, d}, {b, c, e}, {f}}) & /@ data
this is of course somewhat more work than the other solutions, but at least will give a well defined answer. As this second example shows that approach will not fail when there are more keys in the data or these come in another order, and even returns something useful when a key is missing. All that can (and will) happen when you import data in JSON format from a foreign source, as you have learned. Extracting something by position just because in the example you have currently available that part of the data was at that position is highly dangerous and will most probably break in short time...