In general, the way that this typically works (in a no-code/low-code way) is that you would monitor for ALL updates, and then only continue your zap if the order is “won”.

In Zapier, you do that by creating a conditional path. So your conditional path would only continue if the update that was just sent to Zapier was a “won” order.

However, for me personally, I find it much easier to use Integromat to do this, because it’s significantly easier to visualize & control conditional paths in Integromat (and Integromat is much cheaper than Zapier, too).

In Integromat, you use “filters” and “routers” for your conditional paths:

Note that if you want to get even more advanced, you can dive into custom API calls, custom data storage, and/or custom JavaScripting. In those cases, you can typically do searches ONLY for your “won” orders, but that gets more tricky because you also need to keep track of the last time you did a search so you don’t keep returning the same results over & over again. It’s just a little bit more of a complex puzzle that you need to figure out.

p.s. I’m an Integromat Partner and an Airtable consultant — if you ever need to hire an expert to help, feel free to contact me through my website at scottworld.com.

Hi Mark!

It's been a few years, so not sure if this is still an issue you're trying to solve, but wanted to share that Whalesync just launched a 2-way sync Pipedrive integration that works with Airtable and would fix this.

https://www.whalesync.com/sync/pipedrive-airtable

Hi Mark, I understand your challenge with trying to trigger a specific action in Airtable only when a deal is "won" in Pipedrive, and how the standard Zapier triggers might seem too broad.

ScottWorld's suggestion of using a conditional path in Zapier is a solid, no-code approach to filter out unwanted updates, or switching to an alternative like Make (formerly Integromat), which often gives you more control over those conditional workflows at a potentially lower cost.

Beyond the no-code tools, for a highly reliable and immediate solution, you could explore a custom server-side approach leveraging the Pipedrive API, the Airtable API, and a server environment.

Pipedrive's API is robust and supports webhooks for instant notifications on specific events, including when a deal status changes to won, which is exactly what you need.

This eliminates the need for polling and checking "all updates."

You would configure a Pipedrive webhook to send an instant JSON payload to a specific URL when the deal object is updated and the status changes to won.

The server environment could be something like Google Cloud Platform (GCP) or a specialized server-side container platform like Stape.

When Pipedrive's webhook sends the data, it hits an endpoint you've set up, potentially within a Google Tag Manager (GTM) server container that is hosted on Stape or GCP.

Using a GTM server container, even though traditionally for marketing tags, allows you to receive and process HTTP requests from a webhook, which is then managed through a custom tag or client.

Although a direct, native integration between Airtable and GTM for simply sending data isn't possible because Airtable can't host the GTM container, this server-side setup acts as the perfect middleman.

The custom GTM tag, or a script running on GCP, would take the "won" deal data from the Pipedrive webhook and execute a direct API call to the Airtable API to create the new record.

This approach offers maximum flexibility, immediate execution upon the deal being "won", and a single, custom point of control for the entire data transfer, making it a very powerful and precise automation.