And then you can reference it in the later steps…
4 Likes
Could you expand on the use case for this? Is this like a temporary “Thing” basically?
Yes, a variable that is easier to manipulate.
In this case I wanted to get 2 lists, merge them, return data, then do 2 separate actions with each list separately again.
1 Like
@adamhholmes schooled me recently on the most workload unit efficient way to do this. I had been using the make changes to thing trick for years, and just the other day, was told of a better way using custom events.
1 Like
@boston85719
Make changes to a thing as a variable should use the same amount of WU as a custom event that returns a thing via Make changes to a thing. Isn’t it?
No. Make changes has WU implications, check out linked thread.
I understand Make changes has WU cost. But if I need the data from DB used later, even using custom event, I still need to do a query to get it, isn’t it? Or how do you retrieve the data without doing a DB query?
Yes it will…
So don’t use ‘make changes to a thing’ - just return the data from the Custom Event.
You can’t… but you don’t need to use a ‘make changes to a thing’ WF action for that.
@adamhholmes You would only call “make changes” without any change only when you don’t actually make a DB update. Otherwise, you can just use “result of step” as a reference (or pass in to custom event and return it out). If a data is used in multiple conditions later, you need to do one “make changes” or do the same searches multiple times.
Ignoring the fact that using the expression ‘do a search for’ is not synonymous with making an actual database request, that’s correct.
You can indeed use a Make Changes to a Thing action as a ‘variable’ - but as explained in the linked thread, it’s significantly more costly in WU than using a custom event. (test if for yourself and see).
What do you do inside the custom event? I think I am missing that detail from the thread. 
You just return the data from the Custom Event using a ‘Return Data’ action.
CE = custom event for short
Option 1 - result of CE
Backend WF/webhook: process (user_id)
Step 1 - trigger CE get user
=> inside CE, make changes, where user = user_id, return result of step 1
Step 2 - trigger CE process1 if step 1’s result role is admin
Step 3 - trigger CE process2 if step1’s result role is guest
Option 2 - result of direct make changes
Backend WF/webhook: process (user_id)
Step 1 - make changes, where user = user_id
Step 2 - trigger CE process1 if step 1’s result role is admin
Step 3 - trigger CE process2 if step1’s result role is guest
Is there a difference in WU cost? I have only been using option 1 when there are more than 1 step in the CE.
No, there is no difference in WU cost between the 2 examples you’ve given.
Both of them use a ‘Make Changes to a Thing’ action, and so both will incur the same unnecessary WU costs.
@net-tt what @adamhholmes is trying to say is that the CE used as a variable must receive a parameter (let’s say user), then you don’t do anything inside the CE, you just return the data, which will be the value passed to the parameter. Now, you can use this return from the CE to do whatever you want.
1 Like
Custom event needs a parameter, when you schedule or trigger the custom event the parameter needs to be set, which is where you perform the Do a Search, the custom event has return data as same type as parameter, the return data is the parameter.
So still do search but don’t get charged for running make changes to thing or things in order to obtain the results of the search.
1 Like