Canvas Apps offline mode does not push data to the data source

#Issue

A Canvas App is configured for mobile offline mode. The user can enter data while the device is offline, and the device later shows a network connection, but the records are not pushed to the data source.

The device showing Wi-Fi or cellular connectivity does not always mean that Power Apps can reach the required environment, connector, or data source. Synchronization can also be delayed or blocked by an offline profile, a failed submit formula, permissions, validation errors, or a record conflict.

#Applies to

• Microsoft Power Apps Canvas Apps
• Power Apps Mobile
• Dataverse offline profiles and offline-enabled tables
• Canvas Apps using Patch, Collect, SubmitForm, or local collections
• Apps that use SaveData and LoadData for local storage

#Important distinction: Dataverse offline sync versus local storage

First identify how the app stores offline data:

1. Dataverse offline-first functionality uses an offline profile and synchronizes supported Dataverse tables when the app reconnects.
2. SaveData and LoadData store data locally in the app. They do not automatically push records to a data source. The app must explicitly read the local records and call Patch, Collect, or SubmitForm when connectivity is available.

If the app uses SaveData, simply restoring the network connection will not upload the saved records by itself.

#Common causes

• The table is not included in the app's Dataverse offline profile.
• The required columns or relationships are not configured for offline use.
• The app is using SaveData without a reconnect-and-upload routine.
• The app checks Connection.Connected only once and never retries synchronization.
• A Patch, Collect, or SubmitForm operation fails because of permissions, required fields, validation, or a connector error.
• A local record has no stable client-side ID, so the app cannot identify the record during retry.
• The app tries to synchronize before the device has a usable connection to the environment.
• A record conflict or duplicate causes the server operation to fail.
• The user is signed into a different environment or account than expected.
• The app is still running an older published version.

#Resolution

#1. Confirm the app and data-source design

Document the following before troubleshooting:

• The environment URL and environment name.
• The data source and table used by the app.
• Whether the app uses Dataverse offline profiles or SaveData/LoadData.
• The formula that creates or updates the record.
• The local collection or table that contains records waiting to synchronize.

Do not assume that an offline-enabled Dataverse app and a SaveData app synchronize in the same way.

#2. Verify the Dataverse offline profile

If the app uses Dataverse offline-first functionality:

1. Open the app in Power Apps Studio.
2. Open the app's offline configuration or offline profile.
3. Confirm that the target table is included.
4. Confirm that the user has permission to create or update rows in the table.
5. Confirm that required related tables and columns are also available offline.
6. Save and publish the app after changing the profile.
7. Allow the mobile app time to download the updated profile before testing.

If the table is not part of the offline profile, the app may appear to work locally but will not synchronize that table as expected.

#3. Test the connection from inside the app

Show the connection state in a temporary label or status banner:

If(
    Connection.Connected,
    "Connected",
    "Offline"
)

Connection.Connected only reports the device connection state. It does not prove that the app can write successfully to the data source. Use it as an indication to start a retry, and use error handling to confirm the write result.

#4. Add explicit error handling to writes

Wrap write operations in IfError and show the error to the user. For example:

IfError(
    Patch(
        Orders,
        Defaults(Orders),
        {
            LocalRequestId: varLocalRequestId,
            Description: txtDescription.Text,
            SyncStatus: "Submitted"
        }
    ),
    Notify(
        "The record could not be synchronized. It remains on this device and will be retried.",
        NotificationType.Error
    ),
    Notify(
        "The record was synchronized successfully.",
        NotificationType.Success
    )
)

Do not clear the local record until the write succeeds. If the formula removes the local record first, a failed upload can result in data loss.

#5. Implement a retry process for SaveData and LoadData

For apps using local storage, keep a local queue with a stable ID and synchronization status. A basic pattern is:

// Add a new local record
Collect(
    colPendingUploads,
    {
        LocalRequestId: GUID(),
        Description: txtDescription.Text,
        SyncStatus: "Pending",
        RetryCount: 0
    }
);
SaveData(colPendingUploads, "PendingUploads")

When the app starts or the user selects Sync, attempt to upload only pending records:

If(
    Connection.Connected,
    ForAll(
        Filter(colPendingUploads, SyncStatus = "Pending"),
        IfError(
            Patch(
                Orders,
                Defaults(Orders),
                {
                    LocalRequestId: ThisRecord.LocalRequestId,
                    Description: ThisRecord.Description
                }
            );
            RemoveIf(
                colPendingUploads,
                LocalRequestId = ThisRecord.LocalRequestId
            ),
            Notify(
                "One or more records could not be synchronized.",
                NotificationType.Warning
            )
        )
    );
    SaveData(colPendingUploads, "PendingUploads"),
    Notify(
        "The device is still offline. The records remain queued.",
        NotificationType.Information
    )
)

Treat this as a pattern to adapt to the app's data source and error-handling requirements. For large queues, avoid an unbounded ForAll operation and provide a visible progress or result summary.

#6. Add a visible synchronization status

Show users whether records are pending, synchronized, or failed. A useful status banner can include:

• The number of pending records.
• The last successful synchronization time.
• The last synchronization error.
• A Sync now button.
• A message telling the user not to uninstall the app or clear app data while records remain pending.

Example pending count:

CountRows(Filter(colPendingUploads, SyncStatus = "Pending"))

#7. Check permissions and required fields

After reconnecting, test the same user account while online. Confirm that the user can create or update the target record directly in the data source. Check:

• Create and write permissions on the table.
• Required columns.
• Choice, lookup, and date values.
• Business rules and plug-ins.
• Row-level security.
• Connection references and environment variables.

A device connection cannot bypass a data-source permission or validation failure.

#8. Publish and refresh the mobile app

After changing formulas, tables, or offline configuration:

1. Save the app.
2. Publish the latest version.
3. Close the app completely on the device.
4. Reopen Power Apps Mobile.
5. Confirm that the correct environment and app version are being used.
6. Allow time for the offline profile and app metadata to refresh.

#Beginner-friendly test procedure

1. Connect the device to the network and open the published app.
2. Confirm that the app shows the expected environment and user.
3. Create one test record while online and confirm that it reaches the data source.
4. Turn off Wi-Fi and cellular data, then create a second test record.
5. Confirm that the offline record appears in the app's pending list.
6. Restore the network connection.
7. Select Sync now, or wait for the app's documented automatic sync behavior.
8. Confirm that the pending count decreases only after a successful response.
9. Open the data source and verify the record using its LocalRequestId or another unique identifier.
10. Repeat the test after closing and reopening the app to confirm that pending records survive a restart.
11. Test a failed case, such as a missing required value, and confirm that the record remains queued with a useful error message.

#Validation checklist

#Additional information

• Canvas Apps render incorrectly on mobile devices
• Build responsive canvas apps
• SaveData, LoadData, and ClearData functions
• Offline capabilities overview for canvas apps