TillyGen and Airtable

What this is about

Airtable sits between spreadsheet and database: tables whose rows are records, fields with types, links between tables, and the same data shown as grid, kanban or calendar. Production teams use it for inventories — a props table, a wardrobe table, a location fact sheet with parking notes and power access. The TillyGen shot list enters this world through CSV import and becomes the reference table the others link against: which prop appears in which shot, which cast member is needed at which location. The plan defines the shots; Airtable catalogs the things around them.

An integration is good when nobody talks about it any more: the data is where it is needed and nobody exports anything.

What runs differently here

Where this differs from the general case:

• The imported shot list table stays read-only by convention — other tables link to it, nobody types into it
• A props table linked to shots answers in one filter which items must be on set on which day
• The calendar view over linked location records shows booking windows next to the shoot days the schedule dictates
• Re-importing after a plan change means replacing the reference table, not untangling months of mixed edits

Step by step

This order gets you there fastest:

1. Export the shot list from TillyGen as CSV and import it into a new Airtable base as the reference table, fields typed properly on arrival.
2. Build the satellite tables — props, wardrobe, locations, cast logistics — and link their records to the shots they serve.
3. Create the views departments actually use: kanban by prep status for props, calendar over location bookings, grid filtered per shoot day.
4. Work the satellites freely during prep; the linked shot numbers keep every item anchored to the plan.
5. When the plan changes, export fresh, swap the reference table, and let the links resolve against the new state — satellites survive the swap.

Common pitfalls

What most often goes wrong in practice:

• Editing shot rows inside Airtable because it is quicker than opening the plan — the base and TillyGen now describe two different shoots
• Linking satellites to row numbers instead of stable shot identifiers, so every re-import silently scrambles the connections

With TillyGen

TillyGen decides what gets shot and when; Airtable inventories what those decisions require. The CSV import draws the line: shots flow in, and nothing flows back except knowledge in people's heads.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.