Changes made to things' fields sequentially, as with actual code?

Hey, just noticed that the below example of “make changes to a thing” doesn’t work, though logically you’d expect it should. Presumably it makes the changes all at once somehow, so you can’t base later variables on earlier variables? That’s the behaviour it seemed to be showing when I was debugging…

Trouble with that is it means you need extra steps in the workflow, making the whole thing more cumbersome… this example is simple so only needed one extra step (but also wasted an hour trying to figure out why it didn’t work as written). But just seems like it’d be loads better and more logical if changes were made sequentially, ie change field 1, then field 2, then field 3 etc, and hence allowing you to reference earlier fields in later fields. If that’s easy to fix, hopefully it can be added?

Cheers

1 Like

I had the same issue and had to expand the number of actions to compensate. If they change it such that assignments are done sequentially, hopefully the ability to sort them is added as well.

1 Like

I would also like to add that running them sequentially should be optional as well, as running them sequentially might be an extra condition to check, thus lowering performance.

This is a hard fix to do, not an easy one. So you should use more than one action for now.

1 Like

Fair enough, no probs.

Now I know, it’s not a problem for me anymore, since it’s super easy to work around… just if there’s a way you can warn new users of this behaviour, that’d probably save them some stress of trying to debug! I’d think most people would assume it’d be done sequentially unless told otherwise.

Maybe you can make it throw an error message if someone updates one field then references that field elsewhere in the same action (as i did in the screenshot)?

The problem if it did throw an error message would arise when you use This Thing’s X and you actually want to use the original data (I know I have done that in some of my workflows)

But I definitely agree it would be nice to not have to add in another workflow to update a singular data item.

With the example you gave I think you’d be able to put the DemoPotentialCalc part of the formula at the beginning of the DemoPotentialDisp to avoid additional workflows (although lengthy expressions) if that helps at all

Yeah true, maybe just a warning rather than error then.

If implemented it’d force you to write stuff in order, same as you would if you did it in actual code. So it would have the unfortunate issue of breaking some people’s apps until they reordered their commands. I guess this is maybe why it’s hard to implement. Unless it could automatically reorder them with the change so as to not cause any broken apps… sounds messy though.

But anyway, they’re not fixing it so it’s not an issue! :slight_smile:

(And doesn’t use an extra workflow anyway, just an extra action within the same workflow… only a very very minimal inconvenience!)