Change it once.
Keep the next view in step.
Edit the source. Sync the portal. See what happens when a connection fails.
Fictional demonstration · original sample rules and dataUpdate catalogue → copy values → check mismatches
Validated source → versioned update → refreshed portal
Source catalogue
Change one item's price or available stock.
Try a failure, switch the failure off, then retry. The last valid catalogue stays available throughout.
Customer portal
The source owns price and stock. The portal displays that data. Its sample trade view applies an explicit rule.
Watch the 19-second walkthrough
Transcript: Edit the workbench price to $299.95 and stock to 9. Simulate a failure: existing catalogue values remain. Remove the failure and retry: price and stock update. Replay the same event: one applied update remains. Preview the fictional trade rule. No external system is connected.
Silent clip assembled from actual demonstration interaction states.
What this shows, checks and limits
Demonstrated: validated price and stock, source-to-portal updates, last valid data retained after a failure, retries and duplicate/older update protection. A fictional trade view applies a 10% sample discount. Repeat delivery of the same update increments the applied count only once.
Checks: invalid prices/stock, failure/recovery, duplicate delivery and stale updates are covered in the verification record. All data and rules are original; the simulation makes no requests to a commerce or identity provider.
Production scope: agree field ownership and reconciliation; implement authenticated provider APIs, durable queues, authorisation, monitoring and support. This browser-only preview is not an authentication system, live store, checkout or proof of a client result.
Have a similar workaround?
Bring one repeated task. We can discuss a useful, bounded first step.