You might be able to wire something together using the Advanced mode and chained conditionals, but I still don’t think order is enforced there, so even with a rule of “b exists & is not empty” then “evaluate c”, it still might occur before b is defined, so it wouldn’t throw an exception but would still not provide the result you’re expecting. 

Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Apr 22, 2020, at 12:38 PM, Andy LoPresto <> wrote:


Unfortunately I don’t believe there is a way to consolidate this in a single UA processor because currently the application of the attributes is not deterministically ordered, so b may not be available when c is evaluated and applied. The current work around is to use linear dependent processors as you are doing. I do think this is a valid feature request that could be introduced in the UA processor without breaking backwards compatibility if you’re interested in filing the ticket. Changing the internal data structure of the dynamic properties to be ordered _should_ be possible, but I think currently the API doesn’t request that order so it would require a code change there, with a default practice being “order as received". 

PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Apr 22, 2020, at 12:04 PM, dan young <> wrote:


I haven't been able to figure out if this is doable with a single UpdateAttrbute processor, but is it possible to create an attribute that references a different attribute you're setting in the same UpdateAttribute processor?  ie.

a = "foo"
b = "bar"
c = ${allAttributes("a", "b"):join(" _")}

What I've been doing in the past is just have c in a downstream UpdateAttribute....wonder if there's a better way of doing this, or maybe in the Advance section of the UpdateAttribute.