feat(Airtable node): Add support for field ids

[domdomegg]

Summary

Currently, the node requires field names when creating or updating records, but Airtable’s API uses field IDs. This can cause issues, especially when field names change which results in broken workflows.

A similar functionality for targeting tables by ID instead of table name has been discussed and implemented. This PR implements a similar feature for fields.

To avoid this being a breaking change, nodes accept either field ids or field names (by virtue of the Airtable API allowing these to be interchanged). Nodes continue to output with field names, but with the returnFieldsByFieldId option users of this node can opt-in to getting data as fieldIds.

Screenshots:

Without field id output:

With field id output:

Updating a record. Under the hood this now uses field ids, so continues to work even if I edit the column names after saving the n8n configuration:

Plus this also works with returning the updated data with field ids:

Related Linear tickets, Github issues, and Community forum posts

Closes bluedotimpact/bluedot#19

Related:

• https://community.n8n.io/t/airtable-node-target-table-with-table-name-instead-of-id/26067
• https://community.n8n.io/t/airtable-node-target-table-with-table-name-instead-of-id/26067
• feat(Airtable Node): Add Option to Use Field ID's #11666
• feat(Airtable Node): Add support for returnFieldsByFieldId parameter #13328
• feat(Airtable node): Support field ids for robust workflows #14394

Review / Merge checklist

• PR title and summary are descriptive. (conventions)
• Docs updated or follow-up ticket created.
• Tests included.
• PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

[cubic-dev-ai]

cubic found 1 issue across 14 files. Review it in cubic.dev

_{React with 👍 or 👎 to teach cubic. Tag @cubic-dev-ai to give specific feedback.}

[Joffcom]

Hey @domdomegg,

Thanks for the PR, We have created "GHC-2553" as the internal reference to get this reviewed.

One of us will be in touch if there are any changes needed, in most cases this is normally within a couple of weeks but it depends on the current workload of the team.

[Joffcom]

Hey @domdomegg,

Is this any different to the other PRs that are open for the same thing?

---

Quick edit, I remember this issue now. I will get this sorted this week as the original contributor has had more than enough time.

[Joffcom]

@domdomegg looks like there are some conflicts to fix first

[xbinaryx]

I don't understand why my PR was closed. I have been asking and waiting for a review for 4 months now.

[Joffcom]

@xbinaryx I have just answered that on your PR, There is a lot of history with this feature.

[Joffcom]

Is this a breaking change in existing workflows as they will currently be using the name field and not the ID. It might be best to create a light node version like 2.2 and if the node version is 2.2 we use field.id instead of field.name.

This also applies to the other cases like this.