I know this was depracted, but it still worries me that creating a new thing in the step before modifying a thing may miss the new thing in the database.
If I use the thing created in step… then I know that gets the row created in that step. But if I just change a thing then I know from bitter experience that it isnt always available to the script if created a ms before.
At present I have been using two full workflows based on the thing existing or not existing using conditions.
Is there best practice to create a thing (if it doesnt exist) and then make changes to it only using the make changes script step to make the changes?
It’s more for using the result of the thing in a later step than making changes to it afterwards.
For example, if we take a hypothetical social media app that uses hashtags, if a user enters a hashtag, we want to create a hashtag if the hashtag doesn’t exist and make changes to it (e.g increase its # uses by 1) if it does exist. We then might want to add the hashtag to the users message (which will either be the new hashtag or the existing one that was found). It’s a bit tricky to to that final part without two conditionally run actions dependent on which thing is loaded (the thing we created or the thing we changed).
You can use two display data in a group actions - one that runs for the creation action and one for the modification action. Then, you can reference the group’s data in following steps, which will be the created thing or the changed thing.
Well it would mean one script for making all the references to other fields and a single search to check it exists or not,
rather than a search to make sure 0 records exist and create, plus all the row definitions following by a second script test that Makes changes only if >0 records exist.
that two DB search rather than one. It feels that the old. add if doesnt exist did it in one. In a world where we are suspicious or workflow load and cost, then I am always trying to rationalise the number of searches I am doing.
You can only refer to either the result of the last stage or the row you are looking for, so cant be done in one stage i guess, as from experience if you modify a row that has just been create by referring to it, the DB may not have been updated yet and you can miss it.
I guess its still two searches, but just feels clunky!
Ooo I sense a use-case for the Custom event return data feature. Have it lookup or create the thing in the custom event, then return whichever one for use in workflows
