I think I might go about this problem differently, and track the price changes per record (assuming that they only change so often...) - and then tie the sale of an item with that current stock price record. So, for example, there would be a table tracking the cost of products, and the date that the new price became effective - and then, sales of that product would draw from those particular records. I'd use a filtered view with a rollup to hide the previous Hat prices so that only the latest is shown. Pro's and cons with methods I guess. With my suggestion, no automation is required, but an extra layer of table config and record keeping is needed which can be a little difficult to understand at first.
You could do it that way too! My main goal is often to frontload as much work as possible into the design so that the users interacting with the system have it as easy as possible, which I think shows in this approach. Can definitely see value in having a separate table tracking the individual price changes like what you're saying, vs this one which shows history of the price through the lens of sales...
Does the automation not support combining the conditions so you only have one? Triggers: related product is not blank - OR - the existing value is changed --> do the copy/paste of value
I think I might go about this problem differently, and track the price changes per record (assuming that they only change so often...) - and then tie the sale of an item with that current stock price record. So, for example, there would be a table tracking the cost of products, and the date that the new price became effective - and then, sales of that product would draw from those particular records. I'd use a filtered view with a rollup to hide the previous Hat prices so that only the latest is shown.
Pro's and cons with methods I guess. With my suggestion, no automation is required, but an extra layer of table config and record keeping is needed which can be a little difficult to understand at first.
You could do it that way too! My main goal is often to frontload as much work as possible into the design so that the users interacting with the system have it as easy as possible, which I think shows in this approach. Can definitely see value in having a separate table tracking the individual price changes like what you're saying, vs this one which shows history of the price through the lens of sales...
Does the automation not support combining the conditions so you only have one?
Triggers: related product is not blank - OR - the existing value is changed --> do the copy/paste of value