A source can be authoritative and still be incomplete
An inventory feed may own the vehicle’s price, mileage, and availability while the dealership owns a recon note, a local status, or a decision about how the unit should be presented. A naive sync flattens that distinction. It fetches a fresh copy and replaces the workspace because replacement is technically simple.
The result looks current and can be operationally wrong. A local decision disappears without warning, a field that should have remained untouched takes the provider’s blank value, or a new record arrives mixed with dozens of unrelated changes. The integration has optimized data movement while making the manager less able to explain what changed.
Fetch is not commit
LotPro’s bound-workspace flow separates those two moments. The workspace references an approved store datasource, fetches the provider through the existing inventory service boundary, and computes a difference against the current rows. Added and changed counts become a preview rather than a background notification after the fact.
That preview gives the manager a place to ask whether the source should replace the board, update only prices, or add records that do not exist yet. The modes are intentionally concrete. A generic ‘sync’ button would hide the exact policy that determines whether local work survives.
- Fetch through the configured store source
- Compare incoming records with current workspace rows
- Show added and changed records before applying them
- Commit the selected policy in a deliberate batch
Three policies answer three different questions
Replace is appropriate when the source truly owns the complete workspace representation. Prices-only recognizes that the provider can be authoritative for a narrow field while the dealership owns the rest of the row. Add-new protects all existing rows and uses the feed only to discover records the workspace has not seen before.
None of those choices is universally correct, which is precisely why the policy belongs in the interface. The manager can match the merge to the board’s purpose instead of accepting an implementation default. The difference view turns an integration from an invisible overwrite into an explainable operational decision.
Row identity and scope carry the trust
A comparison is useful only if records can be matched consistently. The cited inventory binding keys rows by the provider’s object identity and keeps the source attached to the store configuration. That reduces the chance that two stores or two feeds are treated as interchangeable merely because a vehicle description looks similar.
Permissions still apply after the merge. A source binding does not grant a user access to every column, and an external record does not bypass tenant scope or PII checks. The workspace remains the governed destination; the feed is one proposed input to it.
What the result is and is not
The practical result is an update the dealership can account for. The manager sees what the source wants to add or change, selects the policy that preserves the local decisions the team still owns, and applies the reviewed batch. If a value changes later, the operating story includes a source and a merge choice rather than an unexplained refresh.
The dated build did not exercise live provider credentials during deployment verification, and per-source scheduling was configuration-only rather than an executing job. Preview onboarding must validate real provider behavior and failure handling. Public examples use sample rows and prices; they do not expose dealership credentials or imply partnerships with named providers. A failed fetch must leave the current workspace intact, and a partial response must not be presented as a complete replacement. Those recovery states are part of the merge product, not infrastructure messages to be solved later.
There is also no universal merge policy to automate. A dealership may choose prices-only for one board and replace for another because the boards serve different purposes. LotPro can remember an approved preference, but it should continue to show enough evidence for a manager to understand what the next commit will do.