Hi,
I just wanted to pass on info I got from support regarding an issue I was running into when users signed in for the first time.
For context: My User table in Glide is linked to an Airtable source (which is the core of the issue).
Problem: A user would sign in for the first time, but would not appear in the Glide Editor or Airtable. Any information they saved to their profile would work, but it wouldn’t save. On site refesh all saved information would be removed as that user doesn’t have “a row” in Airtable or Glide.
Here is what engineering had to say:
Engineering has responded. It is an AirTable issue. It would not be an issue if the table were a Glide table. There is not sync involved, so the record would appear instantly. The way our back end works is we record the row in a temporary state and send it to AirTable. We do not show the row in Glide until we get a confirmation from AT that it has been written. We then take the sync off the sync queue list and expose the row in Glide. We have seen the AirTable API to be very slow and non-responsive, which causes us to retry multiple times to get it to sync. Our logs show that the last time it took 7 tries to get the row written.
In short: The Airtable syncing creates a delay with the user creation because the record is not actually created in Glide first. It tries to create it in Airtable (via a temporary state in Glide) first and then syncs it when the Airtable API confirms. So, if Airtable is slow or has an error, it simply doesn’t create that user.
My current solution: This is not ideal but works for me. Create the user in Airtable first before giving them access to their Glide portal. You can do so with something like an application form on your website. When the form is filled out, create a row in Airtable, wait for the sync and then send them an invite to Glide.