[PREVIEW] Users see updated data with “Quick sync”

We are excited to announce the preview launch of the “Quick sync” feature. This feature allows data updates to be available to users within 1-2 seconds of the updates.

As of 5/24 - This feature is available to all users under Preview. Please read below for caveats.

Until now, app users needed to manually sync their app or wait for up to 30 minutes to see the latest data. Issues can arise in your business workflow when users act based on outdated information. For example, imagine a task tracking app where any app user can select a task to work on. When Lydia and Ted open the app at 8:30am when their shifts start, they both see that Task A is available. Ted assigns the task to himself at 8:35am. Because the app doesn’t immediately sync the update, Lydia thinks the task is still available and attempts to assign the task to herself. Depending on how the app is designed. Lydia experiences one of the following:

  • The task is reassigned to Lydia. Ted doesn’t know that Lydia has reassigned the task and ends up doing duplicate work.
  • An error message is displayed. Lydia gets frustrated by the time she wasted trying to find an available task.

With the Quick sync feature enabled, Lydia would see that the task is already assigned to Ted without having to sync the app.

QuickSyncDemo.gif
More generally, it lets users see updated data quickly and without action on their part (including after a data update by an Automation bot), leading to:

  • Faster turnaround times and less errors and unnecessary work in the process, and
  • Less wasted time and confusion among users

Additional details, including caveats, are available below.

Preview offerings are intended for use in test environments only. This feature is not recommended for use in production apps.

How do I enable this feature?

Go to Settings > Performance (1-2) . If you are using the legacy app editor UI , go to Behavior > Offline.

  1. In Sync: Cloud to Data Source, turn on (3) Server Caching and (4) Quick Sync.
  2. Save your app.

Do I have access to this feature?

Feature is available on Free accounts. Based on the feedback, we will gradually release this to paid accounts in the coming months.

When can I enable this feature?

First, the feature currently only works for applications that do not have security filters. The app editor will enforce this. If you have a security filter and turn on “Quick sync”, the feature will be automatically turned off after you save your app and you’ll get a warning message.

When should I disable this feature?

App creators should also consider at least the following factors to decide if they want to use this feature in their apps:

  • The individual data updates will be cached on AppSheet servers. If you have strict data residency requirements, you may not want to use this feature.
  • You should not use this feature if your data sources compute values automatically (for example, if your Google Sheets data source uses formulas) or if your app has virtual columns that require a complete sync to be computed properly. This is to make sure that your users are seeing accurate data and have a consistent user experience.
  • If people change data directly in the data source (for example, editing directly in Google Sheets) or through another non-AppSheet system, the app will not reflect this updated data until the next sync.

Why is it not working for my users?

First, see the restrictions mentioned above (and check that you have no security filters).
In addition, users will only see changes made by other users that are using an app with the same version. This means that if you are updating your app (and the version is changed), your app users may not see updated data until their next full sync.

More technical information is shared further below too.

Where is the documentation?

See the Quick sync setting described in Offline and Sync: The Essentials.

Who should I reach out to if I see issues or want to provide feedback?

Add your feedback or report issues directly on this announcement thread.

How does the Quick sync feature work?

This feature works by “broadcasting” updates directly to the open apps when the changes are done. This allows apps to show the latest data in between full syncs. An overview of the broadcast system is shown in the diagram below.

AppSheet uses the same broadcasting system that is currently used across Google Workspace products like Google Docs and Google Sheets. This broadcast system does best-effort delivery of updates and comes with a few caveats

  • AppSheet will cache updated user content in a queue for up to 6 hours. Data stored in the queue similar to what is currently stored in the AppSheet Audit History.
  • This feature will work with any of the AppSheet supported data sources.
  • If a broadcast notification is not sent due to network issues, the updates will not show up until the next notification or full sync.
  • We do not support any security filters at this time. Support for some security filters will be added in the future, but only for filters that use data from the updated row.
  • The app client (in a user’s browser or on their mobile device) does not fully re-compute all formulas with each update and depends on a full sync for all the formulae to be updated. So the quick sync won’t necessarily reflect what should be the newly computed values. This behavior is similar to what you notice when data is locally edited and the app is set up for delayed sync.

CC: @preethamm @Arthur_Rallu

28 Likes

This is an exciting development. To help us understand how applicable it could ultimately be, please elaborate on the following. I don’t understand what ongoing constraint to expect.

8 Likes

Currently, AppSheet changes are made sending the whole row to the server, and we count on that behaviour.

  1. Does the new Quick sync feature send the whole row when pushing changes or just the field that was update?
  2. If the second, it will consider as “changed” the fields with AppFormula that are not virtual?
4 Likes
  1. It still operates at the row level. We sync physical columns of the row only and let the client recompute the virtual columns on the device.

  2. Anything that updates the row in the origin data source. So this needs physical column data to be updated.

4 Likes

At this point, we are thinking of supporting filters that depend on the updated row only. For ex: [Assigned to] = USEREMAIL(). For anything that depends on Ref columns or SELECT, server will need a copy of the data on client (for referenced tables) and we do not have that cached in the server.

7 Likes

Was so jazzed as I just got through implementing a workaround for this EXACT conflict/race condition issue involving an update key, an appscript, a temp table, and a confusing set of actions/workflows. It works, but it could be better.

Then I read this part:

and now… :cry:

3 Likes

Very exciting!

Great job on this post too, I love the detail, especially the “how it works” part. The link to the help article seems to be broken (or maybe the article just doesn’t exist yet?)

10 Likes

@Marc_Dillon - Thanks for raising this. Link is fixed! :slightly_smiling_face:

5 Likes

Thanks for elaborating.

I’m glad this will be available to use where possible, and understand it’s complex to make available in all scenarios.

Unfortunately, this will be pretty limiting. Straightaway various typical scenarios make an app ineligible–e.g., any use of roles/permission tables (even if those are read-only and, therefore, maybe cached on server?), utilizing a Current User slice to reference a user’s current selections, maybe even referencing a parent table’s security-filtered results in security-filtering a child table.

I look forward to seeing how the feature evolves and learning from innovative community experts how to maximize its use.

6 Likes

Acknowledged. I agree there are lot of legitimate usecases that this will not address. We definitely would like to support these usecases as well. Our next immediate focus is to implement the simple row based filter and then look at ways to expand the coverage.

7 Likes

Tested the function, it’s a great undertaking!

The time for the appearance of changes is only 3-5 seconds!

Thanks to the AppSheet team

3 Likes

I noticed that when activating “Quick sync”, the names of downloaded files are displayed incorrectly:

3-4 minutes after performing the “forced synchronization”, the name returns to the usual

Screenshot_39.png

Please pay attention to this

3 Likes

Created a new app under a free account to test this some, and unless Im crazy, I seem to be seeing the behavior of QuickSync working without having it turned on within the app yet. Can anyone else confirm Im not crazy?

1 Like

Make sure to test with two clients. Apps will push changes in the background, but won’t download them unless Quick sync is on

1 Like

I am. Have the app open with two different accounts on my PC (one in incognito mode) as well as up on my phone. When I make a data change, I see it within seconds in all the other places.

Its about as vanilla of a “new” app as there is. Just created an appsheet DB, and attached a new app to it. Created a few actions to update a DateTime record and an Assignee when clicked. Server caching is OFF, QuickSync is OFF.

3 Likes

Is your data source all AppSheet Databases ? AppSheet Databases has a similar version of this turned on by default. This feature is a complimentary option that applies across all data sources.

4 Likes

Thank you for pointing this out. We will take a look into this

3 Likes

AHH. Thanks @preethamm . Correct, it was only a Appsheet DB. Added a Google Sheet as a source and behavior was as expected on it. Apologies, I had no idea that was an existing feature of AppSheet databases.

4 Likes

Thanks for confirming. Tbh, it is something we missed on our end. I looked around and sync with Databases is not explicitly advertised.

4 Likes

Well that makes me feel better about not being able to find anything about it. :grinning_face:

2 Likes