Job airtable-wide-table-to-linked-tables · revised 11 October 2026
Split one wide Airtable table into linked tables without losing a record
On a duplicate of your base, one table becomes a parent and a child table that reconcile as at a recorded snapshot. You then adopt the duplicate, and we list what that changes.
You might be seeing
- The same customer or supplier is typed on many rows, in slightly different forms
- Counts and summaries disagree because spelling variants are treated as different values
- Changing a contact detail means finding and editing every row that repeats it
No passwords, keys, card details or admin invites needed to start.
What usually happened
A wide table repeats parent information, such as a customer's name and contact details, on every child row. Moving it into its own table means linking each child to exactly one parent. Airtable's linked record fields match pasted or converted text to the linked table's primary field exactly, including spacing, capitalisation and punctuation, so near-matches create extra or blank records, when converting a field a comma inside a value splits it into several links, and a formula primary field prevents new records being created. The job fixes the key and the normalisation rules first, then builds and reconciles the split. A duplicate is a separate base, so the checked result does not change your original. The job records the snapshot it was built from, and ends with a defined way to move your team onto the duplicate.
Who it’s for: An operations manager or small-business owner whose Airtable table repeats the same customer, supplier or project text on every row, so one correction means editing dozens of records.
Usually starts when: Names have drifted into several spellings, reports double-count, and nobody trusts the table as the one place for that information.
The result: On a duplicate of the base, the child table has the same number of records as the original table had at the recorded snapshot, the parent table holds exactly one record per approved distinct key, every child links to exactly one parent apart from listed exceptions, and sampled looked-up values match the old text columns. A cut-over note gives the snapshot figures, a check for records added or deleted since, and the consequences of adopting the duplicate.
Check whether this job fits
Answer these from the table without sending any records or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Count the variants
Group or sort the table by the column you think is the key, and note how many distinct values you see and how many look like the same thing spelled differently. Do not edit any record.
Look for: Roughly how many parents exist and how many records would need a decision.
What you get
- The approved key list with the normalisation rule applied to each variant, and a list of exceptions needing your decision
- The restructured duplicate base, with the child table linked to the parent table
- A reconciliation sheet: the snapshot date and time, record counts before and after, parent count, empty-link count and the sample comparison
- A list of the views, formulas, automations, forms, share links and interface pages that referenced the old columns or the old base, each marked repaired on the duplicate or needing your rebuild
- A cut-over note: what changes when your team moves to the duplicate, the delta check for records added or deleted since the snapshot, and the order of steps for the day
Included
- One table in one base, split into one parent table and one child table linked through a single linked record field
- A key list and normalisation rules, agreed with you before any record is changed, saying which spellings are the same parent
- A snapshot taken when the duplicate is made, with its date and time, the original table's record count and its distinct key count recorded
- Creation of the parent table, linking of every child on the duplicate base, and lookup fields standing in for the old repeated columns
- Reconciliation of record counts, parent counts, empty links and a twenty-record sample you choose
- A cut-over note for adopting the duplicate as your working base: the consequences, and a check you run on the cut-over day for records added or deleted in the original table since the snapshot, which does not find edits to existing records
Not included
- Splitting more than one table, or moving the data to another platform
- Cleaning free text beyond the agreed key and normalisation rules, or deciding which of two genuinely different customers are the same
- Rebuilding interface pages, forms, sync configurations or automations beyond the ones named in the scope
- Repeating the split on your live base: that would redo the checked work on live data without the same verification, so it would be a separate quote with its own reconciliation
- Real personal data leaving your workspace, or any message sent to a real contact
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The child table on the duplicate base holds exactly the same number of records as the original table held at the recorded snapshot date and time.
Evidence: The snapshot figures and the before and after record counts on the reconciliation sheet.
The parent table holds exactly one record for each key on the approved key list and none that is not on it.
Evidence: The parent count compared with the key list, with any difference explained as an exception.
Every child record links to exactly one parent, apart from records on the signed-off exception list.
Evidence: A view of child records with an empty or multiple link, showing zero records or only the listed exceptions.
For a twenty-record sample that you choose, each looked-up value equals the old text value, or differs only where the approved normalisation rule changed it and the sheet says so.
Evidence: The sample comparison on the reconciliation sheet.
The cut-over note's delta check, tested on the duplicate with two records added and one deleted after the snapshot, shows the net change of one record and lists all three records by key.
Evidence: The test log of the delta check and the cut-over note.
Sign-off. You inspect the reconciliation sheet, the duplicate base and the cut-over note, then sign off before payment. You decide when to adopt the duplicate, run the delta check that day and re-point what points at the old base.
If it fails. If the agreed checks do not pass, you do not pay for this scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- You are an owner or creator of the base and can duplicate it for the work
- The repeated information has a usable key, such as a name, code or email, and someone on your side can decide which variants are the same parent
- The table is a normal editable table rather than a read-only synced table, and its primary field can be an editable type during the build
- Your team can move to a different base for this table on a day you choose, re-pointing anything outside the base that used the old one, and either stops editing the original table after the snapshot or keeps its own list of later edits and re-enters them, because the delta check finds added and deleted records, not edits
We stop and tell you if
- The key column is free text with so many variants that nobody can agree which are the same, so a safe key cannot be set
- The table is synced from another base or source and linked records cannot be created in it
- The table is the live system of record for something that cannot pause or be moved to a different base, so a cut-over day cannot be agreed
- The table holds personal data and no secure handover route for the duplicate can be agreed with you
What could go wrong
Your original base is untouched, because all work is on a duplicate. Until you decide to adopt the duplicate, nothing changes for your team. After you adopt it, the original table and its data remain in your original base until you delete them, so you can go back to it, but edits made in the adopted base since the move would not be in the original. We recommend keeping the original and the old columns until you have checked the new structure. Airtable's base trash can restore a deleted field.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Near-matching names are linked to the wrong parent or create extra parent records. | Link only from the approved key list, never by raw text, and reconcile the parent count against that list. |
| A value containing a comma is split into several links. | Airtable documents the comma rule for conversion; the build quotes such values or links by record rather than by text, and the sample test covers them. |
| Deleting the old columns breaks lookups, rollups, filters or automations. | The dependency list names each one and the notes advise keeping the old columns until every item is repaired or rebuilt. |
| Records are added, edited or deleted in the original table after the snapshot, so the duplicate no longer matches your live data. | The snapshot date and counts are recorded, and the cut-over note carries a delta check you run on the cut-over day, which lists records added or deleted since. It does not find edits to existing records, so either stop editing the original table after the snapshot or keep your own list of the edits and re-enter them. |
| Moving to the duplicate leaves forms, shared links or integrations pointing at the old base, or a synced table without its sync. | The duplicate is a separate base, so the cut-over note lists what outside the base must be re-pointed. Airtable documents that a duplicated synced table loses its connection to the sync source and needs it reconfigured. The dependency list records which forms, share links and automations came across on the duplicate, because the pages we checked do not say. |
An independent reviewer checks the redacted before and after evidence, that every test used synthetic data, that nothing outside the agreed scope changed, and whether your authorised owner can safely reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the table, the key, the child and parent fields, the exception handling, the secure handover route and the cut-over day in writing
- Make the duplicate and record the snapshot on it: date and time, record count, distinct values of the key, the empty-key records and the dependency list
- Build the key list and normalisation rules, and have you decide each exception before any linking
- Create the parent table from the approved key list, with an editable primary field, then link every child to its parent and add lookups for the old repeated columns
- Reconcile counts, empty links and your twenty-record sample, repair the named views and formulas that referenced the old columns, and note which forms, share links, automations and interface pages came across on the duplicate and which did not
- Write the cut-over note and test its delta check on the duplicate with records added and deleted after the snapshot
- Independent review of the reconciliation, the cut-over note and what would be lost if the old columns were deleted, then hand over the duplicate base and notes; you decide when to cut over
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, hosting and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If the base grows quickly, discuss a recurring check that new records link to a parent as a separate recurring service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Airtable documents how pasting or converting text into a linked record field matches by the linked table's primary field. A confident Airtable user can follow it for a small table. support.airtable.com
- For a very small table, doing the split by hand on a duplicate base and checking the counts yourself may be quicker than commissioning the work.
Questions
Will you change my live base?
No. The work happens on a duplicate base, which is a separate base. You decide when your team moves onto it, and the cut-over note lists what that changes. Repeating the split on your live base would be a separate quote.
What happens to edits made in the live table while you work?
The duplicate reflects the table at the recorded snapshot. On the cut-over day you run a short check that lists records added or deleted since. It does not find edits to existing records, so either stop editing the original table in the meantime or keep your own list of the edits and re-enter them.
What if two spellings are really two different customers?
That is your decision. We list the ambiguous cases as exceptions and wait for your answer before linking them.
Can you move my Airtable data to another tool?
No. This job restructures one table inside Airtable. A move to another platform is a different outcome.
Send an enquiry
Send us
- The table name, its approximate record count and the columns that repeat parent information
- How many distinct parents you think there are, and which column is most reliable as a key
- Which views, automations, forms or interface pages depend on the table
- Do not send record exports, a base invitation or passwords in the first enquiry
Later, once you agree
- A duplicate of the base shared with a company-controlled identity at the least access the work needs, which you create and can revoke, made only after a secure handover route is agreed with you; none exists in advance, and the first enquiry carries no records
- Your decisions on the exception list and the approved key list
- A cut-over day you choose, and who will re-point forms, shared links and integrations to the adopted base
You keep the live accounts, production keys and customer records. We work only on a duplicate base that you create and can revoke, through a company-controlled handoff agreed before any access; a person owns Synthetic Industry and remains accountable. We do not edit your original base. You decide when to adopt the duplicate and you carry out the move.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “airtable-wide-table-to-linked-tables” as the subject.