we’re going to be rolling out a consistency change which, while minor, has the potential of breaking some implementations of workflows.
This can best be described with an example:
Say you have a workflow with two steps:
- Step 1: Make changes to a Thing, where the Thing to update is a search for that Thing. You are updating Field A to ‘Hey!’
- Step 2: Display data in a Text Group that contains the Result of Step 1’s Field A.
If the search for things returns an actual thing in your database to update, then everything works as it did previously: “Result of Step 1” did and will still contain the thing which you created or updated, which therefore have all its fields, including the updated Field A, and therefore Step 2 will set Group data to text ‘Hey!’
If the search for things returned nothing, you will not be updating anything: Step 1 is basically a no-op.
The results of Step 1 do not contain an actual thing in your database, so all its fields should be empty.
This is where the breaking change happens:
In particular Field A will henceforth be also empty, because nothing was updated, and there are no results to step 1. Step 2 will set Group data to no text, because “Result of Step 1’s Field A” is empty.
Result of Step 1 would contain an extremely barebones ghost Thing, with no id nor any field, EXCEPT for the changed fields, which were inferred to have successfully been updated. Result of Step 1’s Field A would therefore be ‘Hey!’ and the Group Data in Step 2 would be set to text ‘Hey!’.
If you recognize this behavior in your app, and rely on the updated fields even when nothing did change, here’s the suggested change in order to adapt to this update:
Just make sure that instead of using “Result of Step X’s updated field”, write down the equivalent definition you set when changing the property on the ‘Make changes to a thing’ action earlier.
Note: this also applies to “Make changes to a list of things” in the same way.