Loading tutorials…
Loading tutorials…
Airtable is fast to spin up and easy to wire wrong. Most marketing bases hit a wall at 3,000 records or 10 linked tables because the schema was built around the first idea, not the second year of data. This walks the base structure that holds up.
Who this is forFounders and marketing leads opening a fresh Airtable base, or anyone who built one 3-6 months ago and is about to add a second team. If you cannot answer 'which table is the source of truth for campaigns?' in under five seconds, this tutorial is for you.
What you'll need
Step 1
Sketch the 4-7 core objects (Campaigns, Content, Channels, Contacts, Assets, Briefs) and how they relate. This is the single highest-leverage decision in the whole base.
Open a notebook (yes, paper). Write down every distinct "thing" your marketing team tracks. Be ruthless about treating each one as its own object.
For a typical 5-person marketing team, the right answer is 4-7 tables: Campaigns, Content, Channels, Owners, Assets, Briefs, Distribution. Fewer than 4 means you are conflating objects. More than 7 on day one usually means you are over-engineering.
For each object, name: (a) one row = one what? (one row = one piece of content, one campaign, one asset), (b) what fields describe it, (c) what it links to.
Draw the link arrows. A Campaign → has many → Pieces of Content. A Piece of Content → has one → Owner. A Piece of Content → has many → Distribution Channels.
This 30-minute exercise prevents the most common Airtable failure mode: building one giant table that tries to be everything, then realizing in month three that "Asset" and "Content" are different objects.
Step 2
Airtable → My workspace → Add a base → From scratch. Name it for the team, not the project. Set permissions before inviting anyone.
Open Airtable → My workspace (left sidebar) → "+ Add a base" → "From scratch."
Name the base after the team or function ("Marketing Operations," "Content Engine," "Demand Gen Hub") — not after a single project. Bases are organizational containers, not project folders.
Pick a base color and icon — small thing, but with 5+ bases in a workspace, visual scanning matters.
Click the base name dropdown → "Base settings" → set the time zone for the workspace. Recurring automations and date fields rely on this.
Set base permissions now: "Share" button (top right) → invite the core team as Creators or Editors. Reserve Owner for 1-2 people max. Commenters and Read-only for stakeholders.
Step 3
Airtable has 35+ field types. Picking the wrong one (Single line text where Linked Record belongs) is the single biggest source of pain at the 6-month mark.
For each object from step 1, create a table: bottom of base → "+ Add or import" → "Create empty table." Name singular ("Campaign," not "Campaigns") — Airtable will display plural in the UI but the name reads cleaner.
For each table, the first field is the Primary Field — it identifies the row in linked references. Use a human-readable name (Campaign Name, Content Title, Asset Filename) — never an ID.
Pick field types intentionally: Single line text (short names), Long text (rich notes, supports markdown), Single select (status, type — fixed options), Multiple select (tags, categories), Linked record (relationships — the most important field type), Date (deadlines, publish dates), Number (counts, scores), Currency (budgets), Percent (completion), Checkbox (booleans), Attachment (files), URL, Email, Phone, User (Airtable users), Created/Last Modified time (audit), Formula, Rollup, Lookup, Count, AI (new — generative fields).
For status fields, use Single select with locked options. Define statuses now: Backlog → Drafting → In Review → Approved → Published → Archived. Color-code them (greys early, yellow mid, green published).
Avoid Long text for anything you will filter or report on later. Filtering against free text is unreliable; filtering against Single select is fast.
Step 4
Linked records are why Airtable is not Google Sheets. On each table, add the Linked record fields that match the relationships from step 1.
On the Content table, add a field: "+ Add field" → "Link to another record" → choose the Campaign table → enable "Allow linking to multiple records" only if a piece of content can belong to multiple campaigns (usually it cannot).
Airtable auto-creates the reverse link on the Campaign table: a "Content" field appears, showing every Content row linked to that Campaign. This is the magic.
Repeat for every relationship: Content → Owner (User field if owners are Airtable users; Linked record if you maintain a separate Team Members table), Content → Distribution (multi-link to Channels table), Campaign → Brief (single link to Briefs table).
For each Linked record field, add 1-2 Lookup fields to surface useful context inline. Example: on Content, add a Lookup that pulls Campaign.Quarter, so you can group/filter Content by quarter without opening the Campaign row.
Resist the urge to flatten. If you find yourself copy-pasting a value across multiple rows, you have a relationship that should be a Linked record + Lookup.
Step 5
Anything you compute manually is something Airtable should compute. Formulas, Rollups, and Lookups are the difference between a spreadsheet and an ops system.
On Campaign, add a Rollup field: "+ Add field" → Rollup → choose "Content" (linked field) → choose "Status" → aggregation: COUNTIF({Status} = "Published"). This gives you "Published Pieces" per campaign automatically.
On Campaign, add another Rollup on Content.Owner with aggregation ARRAYUNIQUE — shows every contributor on that campaign without manual entry.
On Content, add a Formula field "Days to Deadline": DATETIME_DIFF({Due Date}, TODAY(), "days"). Color-code with a conditional: red if negative, yellow if 0-7, green if 7+.
On Content, add a Lookup field "Campaign Goal" pulling Campaign.Goal — surfaces the parent context inline.
On Briefs, add a Count field for linked Content — shows how many pieces a brief produced, useful for measuring brief-to-output efficiency.
Rule of thumb: if you ever type a value that could be derived, replace it with a Formula/Rollup/Lookup. Manual data drifts; derived data does not.
Step 6
Not every collaborator needs to see every field. Airtable supports field-level + view-level + (on Business+) editor-controlled permissions.
Open a table → field header → right-click → "Edit field permissions" (Team+ tier). Restrict editing of derived fields (Rollups, Lookups) to Owners — prevents accidental override.
Hide sensitive fields from views: in the view side-panel → "Hide fields" → hide cost/budget/internal-only fields from views shared with external stakeholders.
On Business+ tier, enable "Locked views" — prevent collaborators from changing filters/sorts on critical reporting views. The dashboard view of "Q2 Campaign Spend" should not be edit-able by a casual user.
On Business+ tier, configure Record-level permissions on tables with sensitive data (e.g., Owner can only edit content they own).
Audit by impersonating: invite yourself as a Read-only or Commenter user with a second email, then verify the base feels correct from that perspective.
Step 7
Before adding the team, document the object model, field meanings, and "what goes where." This is what prevents schema drift.
Create a "Base Conventions" doc — a Long-text field on a single-row "Base Documentation" table works, or a separate Airtable Doc (on Business+) or a linked Notion page.
Document: each table's purpose (one row = ?), each field type and its meaning (Status: Single select with these specific options, Score: Numbers 1-10, etc.), naming conventions (singular table names, sentence case fields), who owns the base, change-control rules (only base owner adds/removes fields).
Document every Single select option set with definitions. "Approved" should mean the same thing to every team member.
Document the linked records map (Content → Campaign → Brief → Owner).
Revisit quarterly. As the base grows, conventions evolve — but uncontrolled drift is what kills bases.
Common mistakes
Building one giant table instead of multiple linked tables
What goes wrong: Within 3 months you have 60 columns on one table. Half are blank for any given row. Reports are impossible because the data model conflates Campaigns, Content, and Assets. The team migrates to Notion in month 6 — $6-12K in lost setup time plus migration cost.
How to avoid: Sketch the object model first (4-7 tables). Use Linked records, Lookups, and Rollups to relate them. One table per object, never per project.
Using Single line text where Linked record belongs
What goes wrong: You type 'Acme Corp' on 30 rows, then 'Acme Corporation' on 20, then 'acme' on 5. No way to roll up activity by account, no way to filter all-Acme content. Reporting becomes a manual deduplication job that costs 2-4 hrs/week.
How to avoid: Any value that repeats across rows is a Linked record candidate. Build a separate "Accounts" or "Companies" table and link to it. Lookups + Rollups handle the rest.
Not setting Single select options upfront
What goes wrong: Reps create new statuses ad-hoc ('Maybe Approved,' 'Sort Of Done,' 'Pending Soheb'). Within 6 weeks you have 15 status values, half synonyms. Automations that trigger on 'Approved' miss 'Approved!' and a campaign launch worth $20K stalls.
How to avoid: Lock Single select options on day one (Status, Type, Priority). Restrict editing to Owners. Document each option in the conventions doc.
No primary field strategy
What goes wrong: Primary fields are auto-named "Name" with random text. When you link from another table, the picker shows "Name 1, Name 2, Name 3" — useless. You spend 10 minutes finding the right link every time.
How to avoid: Always rename the primary field to something human and unique (Campaign Name, Content Title, Asset Filename). If natural uniqueness is hard, use a Formula primary field combining 2-3 attributes.
Putting derivable data in editable fields
What goes wrong: Manually typed 'Days to Deadline,' 'Campaign Owner,' or 'Quarter' values drift out of sync within a week. Reports show stale data. A Q2 campaign accidentally lands in Q1 reporting and the team misallocates $30-50K of budget.
How to avoid: Use Formulas (Days to Deadline), Lookups (Campaign Owner from linked Campaign), and Rollups (count of published pieces). Anything derivable is a derived field.
No field permissions — anyone can change anything
What goes wrong: A junior coordinator accidentally renames the Status column or deletes a Single select option. Every automation referencing it breaks silently. Campaigns stall for days before anyone notices. Cleanup costs 4-6 hrs of senior time, ~$300-600 of lost productivity.
How to avoid: On Team+ tier, set field-level edit permissions: Owners only for structural fields. Lock critical views on Business+ tier. Document who can change what in the conventions doc.
Recap
Done — what's next
How to build an Airtable content calendar your team will actually use
Read the next tutorial
Hand it off
A clean Airtable base compounds value for years — every campaign, asset, and report builds on the schema. A messy base creates 6-10 hrs/week of manual workarounds and usually gets abandoned within 12 months. A vetted Airtable specialist will model your objects, build the base, set permissions, and document conventions in one engagement — typically $300-600 one-shot, or $400-1,200/mo for ongoing ops work at $14-16/hr.
See specialist rates
Most marketing teams land at 5-8 tables: Campaigns, Content, Channels, Owners (or Team Members), Briefs, Assets, Distribution, and sometimes Metrics. Fewer than 4 usually means you are conflating objects. More than 10 on day one usually means you are over-engineering — add tables as new objects appear, not preemptively.
One base for related work — Marketing Operations should be one base containing all marketing tables. Separate bases for unrelated work (Sales CRM, Product Roadmap, HR). Cross-base lookups exist (via Sync, on Business+ tier) but are slower and more fragile than within-base Linked records. Default: one base per team function.
Single select: one value from a small fixed list (Status, Priority). Multiple select: multiple values from a small fixed list (Tags, Categories). Linked record: any value that exists as a row in another table — Account, Campaign, Owner. If you find yourself wanting to add a description, a relationship, or other fields to the option, it should be a Linked record.
Lookup pulls a field value from a linked record (Content → Campaign.Goal shows the goal of the linked campaign). Rollup aggregates a field across multiple linked records (count, sum, average, ARRAYUNIQUE, COUNTIF). Count is a shortcut Rollup that just counts linked records. Use Lookups for context, Rollups for aggregation, Count for 'how many.'
Airtable AI fields can generate summaries, categorize text, and extract data — useful for triaging inbound briefs or summarizing long content. But they consume credits and add latency. Start without AI fields; add them when you have a specific repetitive task (e.g., auto-categorize new requests) that justifies the cost (~$0.01-0.05 per row depending on model).
Airtable
Most content calendars die in week six because they were built as a list, not as a workflow. This walks the Airtable setup that gives writers, editors, and the CEO each a view of the same data — and stays alive past the first quarter.
Airtable
Airtable as a CRM is great for teams under 5 reps with simple sales motions — and terrible past that point. This walks the right structure for the right team, and tells you bluntly when you should be on HubSpot or Pipedrive instead.
Airtable
Views are why Airtable beats Google Sheets — but most bases have 40 views across 5 tables, half of them stale, none of them documented. This walks the view discipline that keeps a base usable past month three.
Airtable
DIY Airtable is a great idea — until it isn't. This is the honest framework: when the cost of self-managing a base exceeds the cost of hiring help, and how to tell which side you're on.