Setting custom field as primary key instead of default record ID in Airtable

Other Questions Airtable
1

I’m working with an Airtable database that has this structure:

Business    Code

  X         321
  Y         654
  Z         987

I want to use my existing Code column as the main identifier for each row instead of letting Airtable create its own automatic record IDs. Right now Airtable keeps generating its own unique identifiers, but I need my custom Code values to serve as the primary keys. Every time I try to set this up, it seems like I have to replace all the data in my Code field. Has anyone figured out how to make an existing column work as the main record identifier without losing the original data?

2

Airtable doesn’t allow for an existing column to serve as a primary key in the same way traditional databases do. The system automatically generates unique record IDs, which are integral to its structure. You can set your Code column as the primary field for display purposes, but this doesn’t change how records are managed internally. For differentiating records, you can employ the Code column in API calls or automation criteria, but the built-in record IDs will remain active in the background.

3

You can’t actually replace Airtable’s internal record IDs - the system needs them for relationships and syncing. But here’s a workaround that’s worked great for me: Set up your Code field with validation rules to keep it unique, then build everything around that field instead. Treat your Code column as your main identifier and just ignore Airtable’s system IDs running in the background. When I import data or set up automations, I always filter and match using Code values. I’ve used this approach for inventory systems where product codes are the main reference, and it works perfectly. Your existing data stays intact, and external integrations can still reference your custom codes without issues.

4

honestly, airtable’s primary field is just cosmetic - it won’t replace the actual record IDs. i make my Code field unique and use that for everything instead. you can’t change how airtable handles backend stuff, but it’s easy to work around if you don’t mind extra lookup steps when connecting to other systems.

5

Yeah, Isaac’s right about the internal ID thing. Here’s how I handle it.

I use the Code column as my business primary key and ignore Airtable’s internal IDs completely. Make Code your primary field (shows as the record name) and set it as required and unique.

For integrations or automations, always reference records by Code using lookup formulas or filters. I’ve built several systems this way - works great.

Treat your Code column like the real identifier in all workflows. Airtable’s record IDs still run in the background, but don’t reference them anywhere in your setup.

Using the API? Search by Code value instead of record ID. It’s an extra step but keeps your data structure clean.

6

You’re mixing up database concepts with how Airtable actually works. Traditional databases need explicit primary keys, but Airtable handles that automatically in the background. You don’t need to replace any data - just set your Code field as the primary field and turn on field validation to enforce uniqueness. I’ve done this exact thing for client tracking where we needed custom IDs visible to users while keeping Airtable’s internal stuff hidden. Your Code values will work as identifiers for everything users see, while Airtable’s record IDs handle the technical side. This setup’s worked great across multiple projects without any data migration headaches.