Should I create a new row when a ticket changes status?

Only if you want a full history of states. For a current-state log, match on the ticket ID and update the existing row with update_records instead of appending, so each ticket stays a single row.

Is the table updated in real time?

No. Zendesk responds to the agent's call, it doesn't push to Airtable. The log trails real time by your polling interval, which is fine for reporting and dashboards where a few minutes of lag doesn't matter.

ZendeskAirtable

Log Zendesk tickets to an Airtable table

A Zendesk + Airtable agent flow

Zendesk is great at handling a ticket and bad at letting you ask questions across all of them. The moment someone wants to slice support volume by week, tag, or priority and join it against other data, they're stuck exporting CSVs. This recipe keeps a queryable mirror up to date: your agent reads the latest Zendesk tickets and appends each as a row in an Airtable table you can filter, group, and chart. It calls get_tickets, walks the pages, and for each ticket calls create_record with the subject, status, priority, requester ID, and created time mapped to your table's fields. Zendesk answers when asked rather than pushing, so the agent runs on a cadence, every fifteen minutes or hourly, reads the new tickets since last time, and writes one row each.

The flow

Zendeskget_tickets

Fetch the latest tickets with pagination support.

Airtablecreate_record

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

Step by step

Lay out the Airtable table
Create fields for the ticket attributes you'll want to query: ticket ID, subject, status, priority, requester ID, created time, and tags. The ticket ID field is what keeps the log from doubling up.
Read the latest tickets
The agent calls get_tickets and pages through the results. It keeps tickets created or updated since its last run, using the timestamp it stored, so it isn't re-reading the whole history each cycle.
Append a row per ticket
For each new ticket it calls create_record with the fields mapped from Zendesk. If you also want status changes reflected, match on the ticket ID and call update_records instead of creating a second row.
Track the high-water mark
Store the newest ticket timestamp the agent processed. Next run it asks Zendesk only for tickets past that mark, which keeps the job cheap and avoids re-logging settled tickets.

Tell your agent

Every fifteen minutes, fetch the latest Zendesk tickets created since your last run. For each new ticket, create a record in the 'Support Log' table with the ticket ID, subject, status, priority, requester ID, tags, and created time. Track the newest ticket you've logged so you only pull tickets after it next time.

Setup

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

Zendesk install guide Airtable install guide

Worth knowing

create_record writes by Airtable field name, and the value type has to match the column, a single-select for status, a date for created time. Pull the schema once with describe_table and map each Zendesk field to the right column type, or the write is rejected.
get_tickets returns the latest tickets with pagination, so on a busy account the agent has to walk every page rather than trusting the first. Page until you reach tickets older than your last-seen timestamp, then stop.
Airtable's API rate-limits create_record to a few writes a second per base. On a backfill, throttle or batch the creates rather than firing one per ticket in a tight loop.

Questions

Should I create a new row when a ticket changes status?: Only if you want a full history of states. For a current-state log, match on the ticket ID and update the existing row with update_records instead of appending, so each ticket stays a single row.
Is the table updated in real time?: No. Zendesk responds to the agent's call, it doesn't push to Airtable. The log trails real time by your polling interval, which is fine for reporting and dashboards where a few minutes of lag doesn't matter.