Skip to main content
Question

Glide cannot update fields in an Airtable two-way synced table

  • August 24, 2026
  • 2 replies
  • 45 views
L
Forum|alt.badge.img

We use Airtable as the central operational system for a construction company. Approximately 20–25 users work in the base throughout the day, and it manages more than 60 active projects.

Our site managers need a user-friendly mobile app, including the ability to update project information and upload photos from their phones. We originally connected Glide directly to our main Airtable base, but the volume of API activity significantly slowed down the base.

To reduce the load, we created a second Airtable base:

Main operational base → Airtable synced base → Glide

We enabled two-way sync between the main base and the synced base. However, edits made through Glide do not update the synced Airtable fields.

For example, a user checks a checkbox in Glide. It appears checked temporarily, but Airtable never receives the update. The original unchecked value then syncs back to Glide and reverses the change.

We understand that Airtable’s two-way sync may not support edits made through the API, which would explain this behavior because Glide connects through Airtable’s API.

Has anyone successfully built a similar setup?

Would the best architecture be:

  • Keep the operational data synced one-way into the secondary base;
  • Have Glide write changes to regular, non-synced fields or a separate “Mobile Updates” table; and
  • Use Make.com or an Airtable automation to update the corresponding record in the main base?
  • Use another app other than Glide?

We would also be interested in hearing whether Airtable’s native mobile interfaces would be a better option for this use case.

Our main requirements are reliable mobile editing, photo uploads, good performance, and avoiding excessive API activity on the main operational base.

Thank you!

    2 replies

    TheTimeSavingCo
    Forum|alt.badge.img+32

    I’d recommend trying out the Interfaces to see if they work well for you, meets the criteria you set and would be the easiest solve with the downside of probably costing a lot more.  You could do a workaround where you add Fillout links into a read-only Interface to keep costs low, but if your users are used to Glide then having a new form open up in the browser and needing to navigate back to Airtable every time might be jarring

    ---

    I was thinking maybe you could make the Glide base the main base and get your Airtable users to use the synced base instead?  That comes with the downside of the following downsides though:

    1. Automation set up would generally still need to be done within the main base
    2. Record History gets weird with synced records
    Adam, Airtable Consultant - https://thetimesaving.company
    Cloudrocket
    • Cloudrocket
    • New Participant
    • August 25, 2026

    Hi lynx,

    I would start where Adam left it: with a small Interface pilot on the operational base. Have two site managers use the phones they actually carry to test a field edit, several photo uploads, and an interrupted submission. If the mobile flow and access model work, use that. It avoids a second writeback path.

    If Glide stays, I would keep the current main base as the source of truth. Use the one way sync for reads, and have Glide append one row to a separate Mobile Updates table for each requested write. Do not use temporary edit fields on the synced project row. Separate rows preserve the history and stop pending edits from overwriting one another.

    Each update should start as Pending and carry an update ID, the main record ID, the requested values and attachments, the submitter and time, and a version value from the main record, such as the last modified time for fields the mobile flow can edit. Change it to Applied only after the main update is confirmed. A caught error becomes Failed, and anything left Pending too long should trigger an alert. Show that status in Glide.

    Add a RECORD_ID() field to the main table and include it in the sync. Match on that ID instead of the project title. Do not retry a main base write unless the worker can prove that update ID has not already been applied. If the version value changed after the user opened the record, mark the update as Conflict for review instead of overwriting it.

    Whichever writeback worker you choose, it must do both jobs: update the main record and acknowledge the Mobile Updates row. For photos, mark Applied only after the attachment is present in the main record. Test that path with the real phones and several images before rollout.

    Measure read calls, write calls, and base latency during the pilot. A one way sync may remove Glide's direct reads, but the writeback still touches the main base. Do not assume which side caused the original slowdown.
     

    Herry Choudhary - CloudRocket
    Terms & ConditionsAccessibility statement