Why copy deals into Airtable at all?

To report and combine without touching Pipedrive's UI. Once deals are rows in a table you own, you can build views, roll-ups, and joins against other tables that Pipedrive's reporting won't give you.

How does it not duplicate rows?

Store the Pipedrive deal ID in a field and check it before creating. The agent treats that ID as the key: present means skip, absent means create. That's the whole dedup contract.

Does updating a deal in Pipedrive update the row?

Not by default; this recipe creates rows. To keep values current you'd extend it to update_records when the deal ID already exists, writing the changed fields onto the matched row.

PipedriveAirtable

Log Pipedrive deals to Airtable

A Pipedrive + Airtable agent flow

Reporting on deals out of Pipedrive means living inside Pipedrive's filters, and the moment finance or the founder wants the numbers cut a different way, you're exporting CSVs again. This recipe keeps a running copy of the deals you care about in an Airtable table you control, where anyone can pivot, chart, or join them against other data. Your agent calls deals_list to read deals matching a stage or status, then writes each one as an Airtable row with create_record: the deal title, value, stage, owner, close date, and the Pipedrive deal ID. The Pipedrive server responds when the agent asks, so this runs on a schedule, nightly or weekly, building a log that outlives any single Pipedrive view.

The flow

Pipedrivedeals_list

List deals with pagination and filtering options.

Airtablecreate_record

Create a new record in a table with the given field values.

Step by step

Decide what to log and where
Name the Airtable base and table, list its exact field names, and tell the agent which deals to pull: a pipeline, a stage, won deals from the last week, whatever the report needs.
Read the deals
The agent calls deals_list with your filters and paginates through the matches, reading each deal's title, value, currency, stage, owner, and timestamps.
Write each as an Airtable row
It calls create_record per deal, mapping fields to your table's columns and including the Pipedrive deal ID in a dedicated field so each row points back to its source.
Dedup on the deal ID
Before creating, have the agent check whether a row with that deal ID already exists. New deals get a row; ones already logged get skipped, so re-runs append instead of duplicating.

Tell your agent

Every night, list Pipedrive deals in the Sales pipeline updated in the last 24 hours. For each deal not already in the Airtable 'Deals' table (matched on the Pipedrive ID field), create a record with the title, value, stage, owner, expected close date, and the deal ID. Don't create a second row for a deal that's already logged.

Setup

This flow needs both servers connected to your agent. Follow each install guide:

Pipedrive install guide Airtable install guide

Worth knowing

create_record writes to the exact field names you give it; a typo or a wrong base/table ID fails or drops the value. Confirm the schema once with describe_table and pass field names verbatim.
deals_list paginates. For a backfill, the agent should walk every page; for a nightly run, filter to recently updated deals so it isn't reading the whole pipeline each time.
Deal value comes with a currency. Store the currency in its own field rather than concatenating it into the amount, so Airtable can treat value as a number you can sum.

Questions

Why copy deals into Airtable at all?: To report and combine without touching Pipedrive's UI. Once deals are rows in a table you own, you can build views, roll-ups, and joins against other tables that Pipedrive's reporting won't give you.
How does it not duplicate rows?: Store the Pipedrive deal ID in a field and check it before creating. The agent treats that ID as the key: present means skip, absent means create. That's the whole dedup contract.
Does updating a deal in Pipedrive update the row?: Not by default; this recipe creates rows. To keep values current you'd extend it to update_records when the deal ID already exists, writing the changed fields onto the matched row.