When users create new rows in a Data Source that is dynamically supplied to the app via a Hosted GET, you need to manage how those new records sync between the local device and your central server. Here is how to handle the data handoff smoothly.
The Local App Experience
To provide a seamless user experience, the app needs to display the newly created row immediately after the user submits the form.
- To do this, the app temporarily uses the Form Entry ID as the new row’s unique identifier in the local Data Source copy.
- When your system receives the new form submission (e.g., via a REST connector), it should check if the Data Source field value matches the Form Entry ID.
- If it matches, your system knows this is a newly created record and can generate a permanent, system-assigned ID for it.
Scenario A: Full Row Replacement
If your Hosted GET is configured to perform a full replacement of rows on every sync (using the Rows property), the reconciliation process is automatic.
- The next time the app syncs, it will clear all existing local rows, including the temporary one using the Form Entry ID.
- It will then pull down the complete list from your server, which now includes the new row with its permanent system-assigned ID.
- No extra configuration is needed on your end.
Scenario B: Incremental Updates
If your system optimizes data payloads by only sending incremental updates (using NewRows and DeletedRows), you must manually swap the temporary ID for the permanent one.
- Your web service must track the user’s Device ID alongside the temporary Form Entry ID.
- During the user’s next app sync, your Hosted GET must send the temporary Form Entry ID within the DeletedRows payload.
- Simultaneously, you must send the permanent, system-assigned row data within the NewRows payload.
- This instructs the app to cleanly delete the temporary local record and replace it with the official server record.