Quick sync updates existing rows, but new rows do not appear on another device until manual sync — free prototype

Hello everyone,

I need help with a Quick sync problem in my AppSheet app, KARGO. I am testing it on the free prototype plan with two users and Google Sheets as the data source.

The problem in simple words

Imagine a shared shopping list on two devices:

  • If someone changes an item already on the list, the other person sees the change automatically.

  • If someone adds a completely new item, the other person does not see it until they press Sync.

That is what happens in my app. Changes to existing requests arrive automatically, but new requests do not.

What the app does

The app helps two people coordinate truck loading at a fruit warehouse:

  • The shipping supervisor uses a computer to create loading requests.

  • The warehouse worker uses an Android phone to see pending requests and mark them as completed.

Both people use the same AppSheet app and the same underlying table, called Solicitudes.

Each request includes an order number, load type, loading dock, loading instructions, date, time, status, and a unique ID.

A new request starts with the status EN ESPERA, which means “Waiting.” When the worker finishes the load, an action changes the status to COMPLETADA, meaning “Completed,” and records the completion time.

What works and what does not

  1. Editing an existing request works automatically.

    If the supervisor changes an existing request on the computer, that change appears on the phone without pressing Sync.

  2. Completing a request works automatically.

    If the worker completes a request on the phone, it disappears automatically from the supervisor’s active requests on the computer.

  3. Adding a new request does not appear automatically on the phone.

    The supervisor saves a new request in the app, but the worker’s pending list does not show it. It appears after the worker presses Sync manually.

The new request is being saved. The problem is that the other device does not display it automatically.

Steps to reproduce

  1. Open KARGO on the supervisor’s computer.

  2. Open the pending requests view on the worker’s phone.

  3. Keep both devices online and the app open.

  4. Create and save a new request from the computer.

  5. Check the phone: the new request does not appear automatically.

  6. Press Sync on the phone: the request appears.

  7. Edit an existing request from the computer: the change appears automatically on the phone.

Sync settings already checked

  • Quick sync: ON

  • Automatic updates: ON

  • Sync on start: ON

  • Delayed sync: OFF

  • Server caching: OFF

  • Delta sync: OFF

These settings have already been saved and the app synchronized.

Other checks and tests already completed

  1. We checked the pending view’s filter.

    The view uses a slice with this condition:

    [Estado] = "EN ESPERA"

    The Estado column has "EN ESPERA" as its Initial value. Its App formula and Spreadsheet formula are blank, and Reset on edit is OFF.

  2. We tested a plain table view without a slice.

    We created a temporary Table view directly from Solicitudes, without the pending slice.

    New requests still did not appear automatically. They appeared after manual sync.

  3. We checked security filters.

    No security filters are configured on the app’s tables. The Solicitudes table uses “as app creator” access.

  4. We checked the row key.

    The ID column is a physical Text column with Key enabled. Its Initial value is UNIQUEID(). Its App formula and Spreadsheet formula are blank.

  5. We tested two ways of opening the app on the phone.

    We tested the native AppSheet Android app and Chrome on the same phone.

    The problem happened in both: new requests required manual sync.

  6. We tried switching views.

    Moving to another view and returning to the pending list did not make the new request appear.

  7. We checked app versions and reopened the app.

    One audit entry showed a version difference: local version 1.000171 and app template version 1.000172.

    We then synchronized and reopened the app on both devices to address a possible version mismatch, and repeated the test without making further editor changes.

    The problem continued. I do not have evidence that the version difference was the cause.

  8. We checked Audit History.

    The server recorded the new request as:

    • Table: Solicitudes

    • Operation: Add row

    • Result: Success

    • Request start time: approximately September 24, 2026, at 00:17:32 UTC

    This confirms that the Add operation succeeded. It does not explain why the phone only displays the new row after manual sync.

Additional information that may matter

The app includes a metrics dashboard. Some virtual columns use expressions such as COUNT(SELECT(...)) to count completed loads for daily, weekly, monthly, and annual reports.

I mention this because it may be relevant to Quick sync compatibility. However, I have not confirmed that these calculations cause the problem.

I have not yet tested a completely separate, minimal app without these calculations.

Why this matters for our work

The worker needs to know when a new loading request arrives. They cannot keep pressing Sync throughout the day just to find out whether the supervisor has requested another load.

At the moment, manual sync is the only reliable workaround we have found for new requests.

My questions

  1. What could explain existing-row updates arriving automatically while new-row additions do not?

  2. Is this a known Quick sync issue or a documented limitation when testing on the free prototype plan?

  3. Could virtual columns with cross-table calculations cause this specific difference between additions and edits?

  4. What exact log entry or diagnostic should I check next to find out whether the new row is being delivered to the receiving device?

  5. Has anyone experienced this same behavior and found a confirmed fix while testing on the free plan?

I am happy to provide more settings or sanitized logs. I would appreciate a specific next diagnostic step, since the checks above have already been completed.

Thank you for your help.