Locking Externally Owned Fields in Airtable with Field Editing Permissions

A customer's phone number lives in two places: Salesforce, where the sales team maintains it, and the Customers table in Airtable, where an integration writes a copy through Airtable's API for the support team. The ownership map says Salesforce owns Phone and Airtable only reads it. Nothing in the base enforces that, though. Any editor can type over the number in the grid, an interface with an editable Phone field lets a support agent change it mid-call, and any integration with a token for the base can write to it. When one of them does, Airtable and Salesforce disagree until the integration next writes that record, or, if the integration also writes back to Salesforce, the wrong value travels the other way.

InAir's guide to operating Airtable inside complex, high-volume system landscapes sets the rule in its Non-Authoritative Read-Only Lock: "If a system is not authoritative for a field, it must not write to that field." Cross-System Source of Truth decides which system owns each field. This post covers how to make that decision hold inside Airtable: which account the integration should write as, how to restrict the field to it, what the restriction covers and what it doesn't, and how to test it.

What Field Editing Permissions Cover

Airtable's field editing permissions let a base's Owners and Creators restrict who can edit the values in a field. They're available on Team, Business and Enterprise Scale plans, and they aren't limited to the grid. Airtable's documentation says they apply "anywhere that edits can be made," naming interfaces, the mobile apps, extensions and the API. For integrations, the same article answers the exact question this post is about: editing can be limited to an integration "if you limit editing to the specific user whose personal access token is used by the API script or integration," or, for OAuth integrations, to "the user who authorized the OAuth integration."

That makes the lock an account-level rule. The permission is set per user, not per token or per integration, so the field can be locked to the integration only if the integration is the only thing writing as that account.

The “permissions” row is the one real limit of the lock. The permission controls who can edit a field’s values, and the documentation is explicit that it doesn’t control who can change its configuration, so anyone with Owner or Creator access can still lift it. Automations and forms are blocked only if the matching options are unticked when the permission is set: “Allow this field to be modified by automations” and “Allow this field to be set in records created through forms.”

Choosing the Account the Integration Writes As

The lock only works if the integration writes through an account that nothing else uses. An integration running on a person's own token fails that test in two ways. Restricting Phone to that person still lets them edit it by hand, and every other integration they've connected with the same account inherits the right to write it. It also depends on that person staying: if their account is removed, the integration loses its access.

There are two ways to set it up, depending on how many integrations write to the base.

• A dedicated account for each integration. Create an Airtable account used only by this integration, such as a salesforce-sync@ address your team controls, add it to the base with edit access, and keep its login with the integration’s owner. It’s an ordinary account, so it can sign in and counts as a collaborator on your plan, which makes it important that nobody uses it for anything else. This is the only setup that guarantees no other integration can write the locked field.
• One integration account shared by several integrations. If several integrations run through the same account, each with its own personal access token, restricting Phone to that account lets every one of them write Phone. The risk is usually small, because each sending system only reaches the base it was set up for, but it’s a risk the lock can’t remove. Use a dedicated account for any integration that writes a field another system owns.

The fewer integrations an account serves, the fewer systems the lock has to trust.

The Integration Load framework treats ownership as one of its containment factors, and this is where an ownership decision becomes something the base checks rather than something people remember.

Setting Up the Lock

Create the account. Set up a dedicated Airtable account for the integration, as described above.

1. Give it access to the base. Add the account to the base with edit access.
2. Create its credentials. For a token, create a personal access token for that account with the scopes the integration needs, typically data.records:read and data.records:write, and grant it access to this base only. For an OAuth integration such as a middleware connection, authorize it while signed in as the integration’s account.
3. Move the integration onto it. Replace the old token or connection in the integration’s configuration and confirm that a normal run still writes Phone.
4. Restrict the field. As an Owner or Creator, open Phone’s field editing permissions, limit editing to the integration’s account, and untick “Allow this field to be modified by automations” and “Allow this field to be set in records created through forms.”
5. Tell the team. People who used to edit Phone now can’t, and they need to know what to do instead.

If anyone, or anything, currently writes the field besides the integration, find out before step 5. The pillar’s version of this example runs a logging phase first: a Last modified by field scoped to Phone shows who made the latest change, and an automation logs every edit not made by the integration’s account to a review table without blocking it. Once that log shows nothing unexpected, the restriction goes on. Any automation that still writes Phone will start to error once the lock is on, so update or turn off those automations before step 5.

Keep the order in mind if the integration’s credentials ever change. If it moves to a new account before the field’s permission is updated, the new account won’t be allowed to write Phone, so update the permission to the new account as part of the switch.

When Someone Needs to Change the Value

The lock removes an option people were using. A support agent who hears a new number on a call still needs somewhere to put it, and if there isn't one, the number ends up in a notes field or a message, or the agent asks someone with Creator access to lift the lock.

The answer follows from the ownership map: the change goes to whoever owns the value in Salesforce, and the integration brings it back to Airtable. What makes that work, and keeps it from turning into a two-way sync, is a separate field for the reported number. Add a Reported Phone field to the Customers table that support agents can edit, and the integration never reads or writes. An agent who hears a new number on a call enters it there; Phone stays locked. Make the rest the easy path: a button on the support team’s interface can flag the record for review and notify the account owner, who checks the number and updates Salesforce. The new number then reaches Phone on the integration’s next run, from the only account allowed to write it, and the agent can clear Reported Phone once the two match.

Testing the Lock

Run these in a copy of the base, with the integration pointed at it, ideally from a Salesforce sandbox, and check that the field's permission is set in the copy before you start:

• The grid: as an editor, try to change Phone on a record. The edit should be refused.
• An interface: as a collaborator with edit access to an interface page that shows Phone as an editable field, try to change it there. It should be refused, even though the field looks editable.
• A second token: with a personal access token from another editor's account, send an API request that updates Phone. It should be rejected.
• The integration: change the phone number in Salesforce and let the integration run. The new value should reach Airtable.
• Automations: as a creator, create a simple automation with an Edit Record step and try to add a value to the Phone field. Test the step, and it should error.

If your team also updates data through CSV imports or other extensions such as scripting, test each of those the same way, since the documentation doesn't address them.

If you have fields that other systems own and people in Airtable still edit, and you'd like each one locked to the account that should be writing it, Schedule a Discovery Call with InAir and we'll set it up with you.