
Data Modelling
Part of No-code app integrations
Choosing one-way data import before a complex sync
Decide when a batch import or one-way feed is enough, and check matching, removal and product limits before adding two-way sync.
Choose a one-way import when the app needs a controlled copy of source data and does not need to send edits back. Decide whether that copy should be a one-off batch or a continuing feed. The source remains responsible for its facts; the app can keep separate information of its own.
Decide how current the copy must be
A batch import suits a starting list or a reviewed update. A continuing feed suits information that must follow source changes. Set an acceptable delay before choosing the mechanism. A batch copied yesterday should not be presented as a live status today.
If app users need to correct a source value, give them an approved route to its owner. Enabling two-way editing changes who can alter the authoritative record and introduces conflict decisions.
Define matching and removal
List the source fields, app-only fields and identifier used to match a later update to an existing row. Decide what happens when a source row disappears from an import or feed. It may have been deleted, filtered out or missed because an update failed. Check what happens to app-only notes before allowing destination records to be removed.
For a file import, review the field mapping and a small sample first. Power Apps model-driven apps support Excel, CSV and XML imports. Before importing, check that the column headings match the app's column names; map fields manually if they do not.
For a continuing sync, inspect the destination rules. Check whether synced fields or records can be edited, added or deleted, and whether extra destination fields are supported.
Before enabling any removal behaviour, verify which destination records and fields it affects; do not assume source removals are safe to mirror.
Require a reason for two-way editing
Use two-way movement when the task requires edits in both places, the owners agree which fields each system controls, and they have a rule for conflicting or late changes. Check the product's actual write path.
Check whether the product and plan support the required two-way sync, and whether its API permits writes to synced tables. Confirm whether third-party app builders use a supported write path.
Before release, try fictional records with an existing ID, a new ID, a changed value and a removed or filtered source record. Inspect both the copied data and any app-only fields. Record the observed result before granting broader write access.



