Every business that grows eventually discovers the same painful truth: Excel and Google Sheets don’t scale.
They’re incredible tools for ideas, MVPs, and early operations. But once your business becomes real (especially once you have multiple teams, dozens of workflows, hundreds or thousands of data points, and information flowing across departments), spreadsheets stop being helpful and start breaking things.
A recruiting company came to us at Marinext AI with precisely this problem.Â
They had 30+ interconnected Excel sheets, thousands of rows, dozens of VLOOKUPs, manually copied values, separate tabs for each workflow phase, and hundreds of fields for the same people.
On the surface, it looked “organized.”
Underneath, it was a house of cards waiting to fall.
One deleted row could break formulas.
One copy-paste action could corrupt relationships.
One mistake could cost the business days of repair.
They needed a better system.
They needed structure.
They needed relational logic, automation, and consistency.
So we migrated the entire operation—from 30+ chaotic Excel sheets to a clean, automated Airtable system with relational tables, lookup fields, and smart automations.
This article explains the problems we faced, the mistakes we corrected, the automation architecture we built, the mindset shift required for Airtable, and how your business can avoid the same pain.
This isn’t theory.
This is the real story of how we transformed a recruiting workflow from spreadsheet pain into Airtable intelligence.
Why Excel Works… Until It Doesn’t
Let’s start with the root cause.
Excel is excellent at fast entry, flexible data, simple calculations, and early-stage business processes.Â
But Excel is not a database.
It doesn’t understand relationships.
It doesn’t enforce structure.
It doesn’t guarantee uniqueness.
It doesn’t protect data integrity.
This means businesses inevitably run into six critical problems:
Formulas Break When Rows Move
VLOOKUP, MATCH, and INDEX all depend on stable row positions.
Delete a row? Everything breaks.
Insert a row? Everything shifts.
Sort incorrectly? Goodbye accuracy.
In our client’s system, they had built elaborate VLOOKUP chains across multiple Excel workbooks and sheets.
When a recruiter deleted what they thought was a “duplicate” candidate row, it cascaded into 30+ different sheets. Status updates stopped working. Document tracking broke. Salary calculations pointed to the wrong candidates.
The fix required three people spending two days manually reconstructing the relationships.
This happened twice in one month before they contacted us.
Excel Can’t Handle Multi-Table Relationships
You can’t tell Excel: “This candidate belongs to this record in another table.”
Instead, you approximate it with VLOOKUP, filtering, and manual cross-referencing. These work… until they don’t.
Our client had created a complex web of dependencies:
- Candidates Sheet contained basic information
- Status Sheet tracked recruitment phases
- Documents Sheet managed passport, visa, certificates
- Training Sheet recorded completion dates
- Travel Sheet handled flight bookings
- Placement Sheet tracked job assignments
- Salary Sheet calculated payments
- Compliance Sheet monitored legal requirements
- And more
Each sheet referenced others through formulas.
When one sheet changed structure (maybe someone added a column), formulas in six other sheets would break. The team spent hours each week hunting down #REF! and #N/A errors.
Copy-Paste Creates Silent Errors
Imagine a team member accidentally pastes over CndID, phone numbers, dates, statuses… anything. Excel will never warn you. It has no guardrails.
Each error required detective work to trace back to the correct information. Some data was lost forever.
No Automation You Can Trust
Unlike modern database platforms, Excel offers no native automation capabilities for workflows.
There are no triggers, no automated record creation, and no reliable way to propagate data across multiple sheets automatically.
They had attempted to build some efficiency through:
- Complex nested formulas (IF statements with multiple VLOOKUPs)
- Cell references across dozens of sheets
- Conditional formatting as “alerts”
- Macro recordings for repetitive tasks
The fundamental problem: Excel formulas can calculate and display data, but they cannot create records, trigger workflows, or automate business processes. Every action required human intervention, creating bottlenecks and errors.
Data Validation is Nearly Impossible
In spreadsheets, there’s no way to enforce that every record must have a unique identifier, that dates must follow a specific format, or that status values must come from a predefined list.
We found candidates with:
- Status values like “almost done,” “finish soon,” “waiting, I think”
- Dates entered as “next week” or “June maybe”
- Phone numbers in five different formats
- Names with inconsistent capitalization and spacing
This made filtering, reporting, and analysis nearly impossible. Every report required manual cleanup first.
Operational Risk Grows as the Business Grows
More clients = more data.
More data = more formulas.
More formulas = more breakage.
Eventually, the system becomes unmanageable.
This is precisely what happened with the recruiting company we helped. By the time we met them, their internal system was:
- Too big for spreadsheets
- Too complicated to maintain
- Too fragile to scale
- Too risky for operations
They were hiring new recruiters but couldn’t train them effectively because the system was too complex. They were losing business opportunities because data retrieval took too long. They were making costly mistakes because information was inconsistent.
It was time for a new system.
Why Airtable Changes Everything (If You Use It Correctly)
When businesses hear “Airtable,” they think: “A nicer spreadsheet.”
This is wrong.
Airtable is not a spreadsheet.
It’s a relational database with a spreadsheet-like interface.
It allows multiple tables, relationships through linked records, automatic lookups, rollups, real-time filtering, and powerful automations.
It solves nearly every problem Excel creates.
But there is a catch:
If you migrate a broken spreadsheet into Airtable the wrong way… You will create a broken Airtable system.
This happens in 90% of Airtable migrations.
Most teams copy the data but not the architecture.
They attempt VLOOKUP-style formulas, manually link records, rely on physical row numbers, use copy-paste methods, and employ cross-table formulas.
Airtable can’t work this way.
It has its own logic.
You must think like a database designer, not a spreadsheet user.
The Fundamental Difference: Relationships vs References
In Excel, you reference cells: =VLOOKUP(A2, Sheet2!A:B, 2, FALSE)
In Airtable, you link records. You tell the system: “This candidate record is connected to this placement record.” Once linked, all information flows automatically through lookup and rollup fields.
This is the mindset shift that most teams miss.
They try to rebuild spreadsheet logic in a database, but it fails.
What Makes Airtable Powerful
Linked Records: You can connect records across tables with actual relationships, not formula approximations.
Lookup Fields: Once records are linked, you can automatically pull any field from the connected record.
Rollup Fields: Automatically calculate sums, counts, averages, and more across linked records.
Views: Create unlimited filtered views of the same data without duplicating anything.
Automations: Build reliable, no-code automations that survive structural changes.
Field Types: Enforce data integrity with specific field types (email, phone, date, single select, etc.).
Permissions: Control who can view, edit, or comment on specific tables and fields.
But here’s what we learned from this project: None of these features matter if you don’t have the right architecture.
Let me show you how we fixed this for our client.
The Migration Problem: 30+ Tables, 300+ Rows, No Real Primary Key

When we opened the client’s Airtable base for the first time, the structure looked familiar: Candidates, Status, Documents, Training, Travel, Placement, Salary, Compliance… dozens of tables. Each table required data from the others.
But there was one fatal flaw: There was no universal, stable primary key.
Instead, they used PH1_Row (physical row number), which changes whenever a record is deleted. This is how formulas break. This is how automations break. This is how relationships collapse.
Understanding Primary Keys
In database design, a primary key is a unique identifier that:
- Never changes
- Exists for every record
- Is never duplicated
- Has business meaning
Physical row numbers fail on all counts. They change when rows are deleted or sorted. They have no business meaning. They can’t be referenced reliably across tables.
The Solution: CndID as Universal Primary Key
Airtable requires one thing to work reliably: A non-changing, meaningful ID that exists in every table.
For our client, that key already existed: Candidate ID (CndID). Example: 23.01#0047
This ID format contained:
- Year (23 = 2023)
- Month (01 = January)
- Sequential number (#0047)
It was unique, meaningful, and already assigned to every candidate.
We made CndID the universal primary key across all 30+ tables.
That decision alone changed everything.
The Correct Migration Architecture: Build Around One Key
Once we standardized CndID as the master identifier, every table became connected.
The New Structure
Core Principle: Every table gets a CndID column. No exceptions.
Then:
- DB_Phase#1 becomes the source of truth
- All other tables receive CndID automatically
- Airtable links records using CndID
- Lookup fields pull every other field
- No more VLOOKUPs
- No more manual copy-paste
- No more PH1_Row errors
Everything becomes stable, scalable, and automated.
The Parent-Child Hierarchy
We established a clear hierarchy:
Parent Table: DB_Phase#1
- Contains core candidate information
- Name, contact details, nationality, date of application
- This is the only place where this information is stored
- All other tables reference this
Child Tables (30+ total):
- ED_AR Status (recruitment phase tracking)
- Documents (passport, certificates, visa)
- Training (completion dates, certificates)
- Travel (flights, accommodation)
- Placement (job assignments, companies)
- Salary (payments, deductions)
- Compliance (legal documents, expiry dates)
- And others…
Each child table has:
- CndID field (text field, primary key)
- Link to DB_Phase#1 (linked record field)
- Lookup fields pulling Name, Phone, Email, etc.
- Table-specific fields (status, dates, notes unique to that table)
Why This Architecture Works
Single Source of Truth: Core candidate information exists in exactly one place. Change it once, it updates everywhere.
No Duplication: Names, phone numbers, and email addresses are never duplicated. They’re looked up from the parent table.
Automatic Consistency: If a candidate’s name changes (marriage, correction, etc.), update it in DB_Phase#1, and every table reflects the change instantly.
Scalability: Adding a new process? Create a new table, add CndID and link to the parent, done.
Error Prevention: Can’t accidentally paste over a looked-up field. Lookup fields are read-only.
Audit Trail: Airtable tracks who changed what and when in the parent table.
This is the foundation of every successful Airtable system.
Automation A: Syncing 300+ Existing Records Without Manual Work
Migration challenge: We had 300+ existing candidates in DB_Phase#1. We needed them to automatically appear in ED_AR Status, Training tables, Accommodation, Contract, and all other tables.
Manually linking would take days. Writing 30+ automations would be insane. Using CSV imports would create duplicates.
The Initial Approach (That Almost Worked)
We built a single automation:
Trigger: When CndID exists in DB_Phase#1
Action: Create a new record in ED_AR Status (the same as the rest of the tables) with the same CndID
But this only worked for new records going forward. The 300+ existing candidates wouldn’t trigger it.
The Breakthrough: The Copy-Delete-Paste Trick
Then we discovered something brilliant: When you select the whole CndID column, copy it, clear its contents, and paste it back, Airtable treats each row as updated, triggering the automation.
Here’s what we did:
- Selected the entire CndID column in DB_Phase#1 (300+ cells)
- Copied to clipboard (Ctrl+C)
- Deleted all content (Delete key)
- Immediately pasted back (Ctrl+V)
- Watched as the automation fired 300+ times in 90 seconds
What normally takes hours became a 2-second trick.
This method migrated all 300+ records instantly into every child table.

Why This Works
Airtable’s automation triggers detect field changes, not whether the value actually changed.
By deleting and repasting, we forced a “change event” even though the final values were identical.
This technique became our secret weapon for:
- Initial migration of existing data
- Backfilling new tables added later
- Re-syncing tables that somehow got out of sync
- Testing automations at scale
Automation B: Syncing New Candidates Automatically
Migration is only step one. The system must also work for the future.
So we built Automation B:
Trigger: When a new record is created in DB_Phase#1
Action: Automatically generate a record in the child table with the same CndID
Now, whenever a new candidate enters the system:
- All linked fields populate automatically
- All lookups update
- No manual syncing needed
- No formulas required
- No risk of missing values
- No dependency on row numbers
Automation Best Practices We Learned
Keep automations simple: Each automation should do one thing well. Complex multi-step automations are more complicated to debug.
Use conditions wisely: Add filters to prevent unnecessary runs. “Only run if status = X” prevents wasted automation runs.
Test incrementally: Build one automation, test thoroughly, then build the next. Don’t build all at once.
Document everything: We created a separate “Automations Guide” table listing every automation, what it does, and when it runs.
Monitor the automation log: Airtable shows automation history. We check it weekly for failures or unexpected behavior.
This is real operational automation.
The Most Important Insight: Automations Should Only Do ONE Thing
Most Airtable beginners try to update fields directly, build VLOOKUP formulas, manually sync data, recreate Excel logic, and patch fixes with automations.
But the truth is:
Automations should not move data.
Automations should create links.
Once the link exists:
- Lookup fields pull the data
- Rollups summarize it
- Hidden errors disappear
- The system stays consistent
The Right Way (What We Built)
In the new Airtable system:
- CndID exists only in DB_Phase#1
- Every other table has a lookup field pulling CndID
- No automation needed to “sync” the CndID
- Impossible for data to become inconsistent
Automations only create the initial link (CndID connection). Lookups handle everything else.
This creates a “single source of truth” structure that every business needs.
Common Mistakes Excel Users Make (And How We Fixed Them with Airtable)
Mistake 1: Using Row Numbers as IDs
The Problem in Excel: They had formulas referencing “row 47” and “the 12th entry.” These broke every time someone deleted or sorted rows.
How Airtable Fixed It: We created a stable business-level ID (CndID) as the primary key. In Airtable, records maintain their identity regardless of sorting or filtering. No more broken references.
Mistake 2: Using VLOOKUP to Connect Data
The Problem in Excel: They had dozens of VLOOKUP formulas like =VLOOKUP(A2, Documents!A:Z, 5, FALSE) connecting information across sheets. These broke when columns moved or sheets were renamed.
How Airtable Fixed It: We replaced every VLOOKUP with linked records and lookup fields. Link once, pull any field automatically. Changes in structure don’t break anything.
Mistake 3: Manually Copying Data Across Sheets
The Problem in Excel: Each new candidate required 15-20 minutes of manual copy-paste across 30+ sheets. Recruiters had to manually enter the same name, phone, and email in multiple locations. Frequently forgotten, always error-prone.
How Airtable Fixed It: Automations create linked records instantly. Lookup fields pull all information automatically. Zero manual work, zero errors.
Mistake 4: Duplicating Information Everywhere
The Problem in Excel: Candidate names appeared in 20+ different sheets. Phone numbers in 15+ sheets. Every piece of information was copied and pasted multiple times. When something changed (e.g., a name correction or a new phone number), it had to be updated manually in 5-10 locations.
How Airtable Fixed It: Single source of truth in DB_Phase#1 and two other main tables. Every other table uses lookup fields that automatically update when the source changes. Update once, and it propagates everywhere instantly.
Mistake 5: Complex Nested Formulas for Business Logic
The Problem in Excel: They had built formula fields with nested IF statements trying to “find” related records: =IF(A2=””, “”, IF(VLOOKUP(A2, Sheet2!A:B, 2, FALSE)=”Active”, “Process”, “Wait”)). These were fragile, hard to maintain, and broke constantly.
How Airtable Fixed It: We replaced formula-based relationships with properly linked record fields. We kept formula fields only for simple calculations (age from birth date, days until expiry). Links define relationships; formulas do math.
Mistake 6: No Primary Key Validation
The Problem in Excel: Some candidates had no CndID. Some had malformed IDs. Nothing prevented this. No way to quickly identify the problem.
How Airtable Fixed It: We made CndID a required field in every table. We built a validation view showing any records with missing or malformed CndIDs. We set up weekly checks. Airtable’s structure prevents many of these errors from happening in the first place.
Mistake 7: No Audit Trail
The Problem in Excel: When data was wrong, nobody knew who changed it, when, or what it was before. Investigating errors was detective work through multiple people’s memories.
How Airtable Fixed It: Airtable automatically tracks every change: who edited what field, when, and what the previous value was. Full audit history for accountability and error recovery.
Final Thoughts: Airtable Intelligence vs Spreadsheet Pain
Excel is an incredible tool.
But it was never meant to run complex operations with 30+ interconnected workflows.
Airtable is the modern solution, but only if you build it with exemplary architecture.
If you try to use Airtable like Excel, you’ll fail.
If you rebuild your workflows around relational logic, you unlock:
- Cleaner operations
- Less manual work
- Fewer mistakes
- Instant automation
- Better reporting
- A scalable system
This transformation isn’t just technical. It changes how a business operates.
Our recruiting client now has:
- Reliable data they can trust
- Real-time status tracking across all processes
- Automated updates that never fail
- Reduced operational risk
- Complete operational clarity
This is Airtable intelligence.
And it’s how modern businesses scale.
Key Takeaways for Your Business
If your business is struggling with spreadsheet complexity:
- Audit your current system – Understand the pain points before migrating
- Identify your primary key – What unique identifier connects everything
- Design the architecture first – Don’t just copy data, redesign relationships
- Build parent-child hierarchy – Single source of truth with child tables
- Use linked records, not formulas – Let Airtable handle relationships properly
- Automate links, not data – Automations create connections; lookups move data
- Test incrementally – One table, one automation at a time
- Train your team – Database thinking is different from spreadsheet thinking
The complexity of your business doesn’t have to mean chaos in your systems. With the right architecture, Airtable transforms operational pain into operational intelligence.
And that transformation is available to any business willing to think beyond the spreadsheet.