Please exclude the naivety of this question if I’m missing something obvious.
Is there a way to query the value of a retrieved property from the client relevance language. e.g. some of the Retrieved properties go through a complex effort to reduce a number of elements to a singleton, it would be useful to just be able to access that directly rather than having to reproduce the same effort each relevance/action where you need it.
Yes. You are correct that there is no way to do it. This is by-design of the product.
You run into all sorts of problems with “references” and if we allowed them, it could easily cause all sorts of unintended consequences (like if you changed a property and all the sudden a bunch of Fixlets/Actions changed becaues they were referencing a property). There are also some security complications (what if you make a Fixlet based on a property, who should be allowed to change the Fixlet?)
It is these sorts of issues (and there are a lot of them) that makes us avoid using references wherever possible.
When we initially were designing BES, our developers and architects spent hours and hours discussing this at great length and the conclusion was “references are evil”. They certainly will make some tasks easier as you mention, but there is a cost associated.
In my current case I was looking for access to a “Location by Subnet” property, which I just realized is crafted as a local setting on the clients that you could get at. I guess that is a workaround for this issue for things that are “that complex” to compute in a large environment and shouldn’t be in every script because of the possibility for changes to the rules, etc.
I do recognize the other reasons for avoiding this dependency, and I do agree with them on that basis.
Yes… Good point… I should have mentioned that you can store values in settings…
It is something that is helpful in cases where the relevance is very long and often used in targeting (in fact, you would run into significant problems if you didn’t use a setting to store the result of such a long query).