Hi @pauljlange —
First, I'd be curious about which CRM you're using. Some have a function that will handle the duplicate checking automatically when the contact is added. One example that comes to mind (since we work with it often) is Infusionsoft. Their standard Zapier integration actually allows you to configure duplicate checking and add or update the lead (depending upon whether it already exists or not) within one Zap step.
If the CRM you're working with doesn't have a capability like the one I described, it may allow you to run a "Search step" which you could use to check for the contact before proceeding. You could then use Paths to set up conditional logic for how to proceed based upon the results of the search step (i.e. Path A adds the contact if it wasn't found in the search step, Path B updates the contact if it was found).
If you always want to execute the same functions next, you could build one Zap to execute the next steps for each. This probably gets more to the heart of your question. Your "next steps" Zap should begin with a Webhook trigger, and then at the end of each of your Paths, use Webhooks by Zapier to send a webhook to the URL that is the Trigger Step for your "next steps" Zap. The webhook step at the end of each of your "paths" would need to pass appropriate data (e.g. Contact ID for your CRM plus any specific data points that your "next steps" Zap might need to refer to) which will then be received by the Webhook at beginning of the "next steps" Zap. From there, you can add whatever actions you need, and you don't need to worry about always maintaining multiple copies of the same steps.
You could also use a Google Sheet like you mentioned, but the Webhooks are a little cleaner — at least the way I look at it. You're not pushing data out of Zapier and then bringing it back in — at least not in as complex a manner.
I hope this makes sense! By all means let me know if I muddied the waters for you here. I'd be happy to clarify.
Cheers!
I like the idea of using webhooks in that way @TheDavidJohnson , though, we would be keen too on merging paths like @pauljlange suggested, in a number of different scenario's.
The problem with that webhook approach is a workflow ends up getting spread over multiple zaps which is more challenging for a new person to unpack if they have to fix something, as opposed to having the whole flow in one zap.
Fair enough, @Optimi — one Zap would be simpler, on the face of it.
On the other hand, a "modular" approach allows you to reuse a given sequence of steps that you package up as a single Zap from an unlimited number of "source" Zaps. It's a little like breaking out a function when you're writing software. Rather than have to write it every time, you can just "call" it when you need it.
For now, since merging multiple branches back into a single branch within a Zap is not possible, I'm not sure there's a better way to handle a situation like the one that @pauljlange articulated. The more I've thought about it, the more potential difficulties I see with even trying to create that functionality. But given the amazing things that Zapier engineers have built in the past, who knows? Maybe they'll find a way to make it happen!
@TheDavidJohnson Seemingly merging paths can work - if you check out Integromat they do it pretty nicely.
Although when you’re getting to this level of complexity I agree that breaking out the zaps in the way @pauljlange describes is better from a troubleshooting/maintenance point of view.
@Andrew_Luhhu — I'm sure it's technically feasible, I didn't mean that, exactly. I was specifically looking at Zapier's architecture and imagining the difficulties involved. It can be difficult to keep users out of trouble, and reuniting divergent paths means that you end up with potentially very different data structures and outcomes and so forth. I could definitely see why it might be better to avoid that scenario. But again, there are much smarter people than me working on this stuff! Cheers!
