This guide covers the most common sync failure patterns on the Access Care Planning mobile app. Work through the relevant section before raising a support case. Most sync issues are resolvable without engineering involvement.

This usually means the device cannot complete the initial data download from the server, or a previous sync attempt was interrupted.

Step 1 — Check your internet connection. Confirm the device has a stable Wi-Fi or mobile data connection. Open a browser and load a webpage to verify the connection is working, not just connected.

Step 2 — Close and reopen the app. Force-close the ACP app entirely (do not just minimise it), then reopen it and attempt to log in again.

Step 3 — Attempt a clean sync. If the loading bar freezes again after reopening, the device may have corrupt or incomplete local data. Perform a clean sync. See the Device sync article for instructions. Do not perform a clean sync if you are in the middle of a visit or have forms open — all unsent data will be deleted.

Step 4 — Check the app version. Ensure the device is running a supported version of the ACP app. Go to the device's app store and check for updates. Outdated app versions are a common cause of persistent sync failures. Tenant Administrators can enforce minimum app versions via the App Upgrade Policy in tenant preferences.

Step 5 — Raise a support case. If the loading bar continues to freeze after completing the above steps, raise a case via the Access Digital Assistant. Include the device type, OS version, ACP app version, and what you see on screen.

If a carer's device shows a successful sync but visits are still missing, work through these checks.

Step 1 — Allow for integration lag. If the visit was recently created or updated in your rostering system such as Access People Planner, allow up to 20 minutes for visits starting within 72 hours, and up to 24 hours for visits starting beyond that window. Changes to existing visits follow the same timings.

Step 2 — Check the carer's username. Visits are assigned to an employee record. If the carer has two usernames in the system (their standard login and an integration username), the visit may be assigned to the integration username, which is typically in numeric format such as 2-xx. Confirm which username the carer is logging in with.

Step 3 — Confirm the visit exists on the web console. Log in to ACP on the web and check the service user's Visits tab. If the visit is not listed there, it has not been created in ACP and the issue is upstream in the rostering system. If it is listed on the web console but not on the device, proceed to step 4.

Step 4 — Perform a clean sync on the device. A clean sync forces the device to download all data from scratch. This resolves cases where the standard sync failed to transfer the new visit. See the Device sync article for instructions.

Step 5 — Check the carer's role and branch assignment. The carer must have a role with access to the service and be subscribed to the service user's case. Without this, visits will not appear even after a successful sync.

A completed sync does not always mean all data has been refreshed. The standard sync (delta sync) only downloads data that has changed since the last successful sync timestamp. If the timestamp was recorded before certain changes were made, those changes may not be included.

Step 1 — Perform a clean sync. A clean sync resets the timestamp to zero and downloads all current data from the server. This is the correct resolution when a standard sync consistently fails to bring through new visits, activities, or forms.

Step 2 — Avoid performing a clean sync during an active visit. All locally stored data on the device — including completed forms not yet uploaded — is wiped at the start of a clean sync. Only perform a clean sync before starting visits or after all data has been confirmed on the web console.

Step 3 — Check the user device relationship report. Tenant Administrators can review a carer's actual sync history via Reports > Other Reports > User Device Relationship. This shows the last API call time and last successful sync, which confirms whether the device is genuinely connecting to the server.

A clean sync is appropriate in these situations.

The device is showing an older version of visit data and standard syncs have not resolved it.

A new user is logging in to a device for the first time.

The device has been offline for an extended period and is out of step with the server.

Standard sync completes without errors but new visits or activities are still not appearing after 30 minutes.

The following defects are currently open and may cause sync failures in specific scenarios. If your situation matches, raise a support case and reference the issue description.

Android clean sync fails on initial user login in specific scenarios. A known defect on Android can cause the clean sync to fail when a new user logs in for the first time under certain configuration conditions. If a new carer cannot complete a clean sync on initial login, raise a support case with the device type, OS version, and app version.

Sync Failed message when the screen turns off during form submission. If the device screen turns off at the moment a form is being submitted, a Sync Failed message may appear even though the form data may have been saved successfully on the server. Perform a standard sync and check the web console to confirm whether the submission arrived. If the submission is not on the web console and the sync fails to resolve this, raise a support case.

Deleting a form from a section requires a clean sync before the form is hidden on Android. If a form is removed from a section in the web console, Android devices require a clean sync before the change is reflected in the app. A standard sync will not remove the form from the device. Perform a clean sync to apply the change.