Hi there! Tim here from the Zapier Support Team with a workflow idea.
Have you ever had a Zap where you’d search for a value from a Trigger in another app, like a Google Sheet, with a Find Step but if the value isn’t found, the whole Zap is ‘Safely halted’ because the next Steps in the Zaps depend on the search?
Have you wanted to continue the Zap with default value(s) but found that using a Formatter Text Default Value Step also gets halted due to a dependancy on the Find Step that didn’t return anything?
If so, you’re not alone! Read on for a few ways around this.
1) Use Find or Create instead of just Find
This won’t always be an option, but some apps include the ability to create a record if one isn’t found. If your app has the option to Create a Record if one isn’t found by the search, and you don’t mind having entries with default values added to your data, then:
- Turn on the “Create Record if not found” checkbox
- Fill out the fields with default values that you’d want to use in the Zap if a record isn’t found.
Now, the Step can’t ‘Safely halt’ because some data will always be returned - either a found record, or a new record’s default values.
2) Use Paths to run different versions of your Zap if a record is found or not
If your Zap isn't too long/complex, Paths can be a good option.
After your Find Step that might get Safely halted, add a Path with two branches. Choose a very common value that will always be there if a record is found like ‘ID’ and then:
- Only continue if … ‘ID’ value from the Find Step ‘Exists’
- Set up the rest of the Steps for your Zap as normal in this Path
- Only continue if … ‘ID’ value from the Find Step ‘Does not exist’
- Set up the rest of the Steps for your Zap in this Path like Path A, except type in Default values into Steps instead of mapping any values from the Find Step that might halt.
- Double check that in the Path where the Find step is expected to halt that we don't use any of the values from that search Step, or those Steps will still stop. You can type in default values instead.
For example, here’s a screenshot of the Task History for a Zap where the Find Step halted, but the Path checking for that still ran:
3) Storage by Zapier
If your Zap is too long for Paths to be easy to maintain or you can’t create values with default records in them, or you don’t want to, Storage by Zapier is another great option for working with this issue.
Here’s an overview of the idea:
- The Zap Triggers
- Store some default value(s)
- Search a record/some values with a Find Step
- Try to overwrite the default value(s) with the results from the Find Step. If the find was halted, this Step won’t run either.
- Retrieve the stored values, which will either be the defaults we set before, or the found values that we replaced the default values with.
- Use the retrieved values (default or found) in the next Steps of the Zap.
Here’s how it looks in practise:
First, set up your Trigger and other Steps before the Search, then add a Storage by Zapier ‘Set Value’ Step:
With each Storage Step, you’ll want to set the Key as some unique value from your Trigger. I’ve used the email address in this example. This prevents multiple runs of the Zap overwriting each other, since they will be using different locations in Storage based on different key names.
Then, we can run our Find Step as normal:
We try to save the result of the search over the default value. In this example, the value we were retrieving via the email address was “Name” from Google Sheets:
Notice how we’re still using the same Email value from the Trigger as our key here and especially in the next Step.
Finally, we retrieve the value again using Storage’s ‘Get Value’ Step:
We can now use the value from the Get Value step which will contain either the found value, or the default, being careful not to map the results from the Google Sheet Step into any later Steps.
While I was writing this, I came across another excellent example of this written by
If you have any questions about this, let me know in the conversation below!