GlobalRetail: One Customer Data Page, Four Case Types, Twenty Calls

Precondition: the page must be keyed by customer.

Scope and reload decisions only make sense if the page is parameterized (customer ID in, one customer out). A data page that holds "the current customer" is a single mutable page and no amount of tuning will stop the cross-case contamination you are seeing.

Scope options and what they mean

• Thread (the default): a separate copy per clipboard thread. Safe, but every thread that opens the page issues its own call, and copies drift apart when one is edited.
• Requestor: one copy per logged-in user. Fewer calls than thread, still one per user, and wrong for anything an operator can edit and expect to see reflected for others.
• Application / Node: shared across requestors. Right for read-mostly reference data, but only if the content does not vary by operator - a node-scoped page is shared by everyone on the node, so it can never carry operator-specific filtering or permissions.

Choice

A CRM customer record is reference data, read-mostly, reused across four case types and multiple users. Application or node scope, with a reload strategy of "reload if older than" a business tolerance (10–15 minutes for address and contact data) rather than always reload.

Where that is not enough

• When the address must be current at the instant of decision (confirming an address change, sending a payout), use a second, explicitly refreshed page for that step rather than shrinking the interval for everyone.
• The twenty calls are also a UI problem: if the review section's refresh action re-opens the data page each time, caching alone will not save you. Refresh the smallest region you can and let the page hit cache.
• After Address Change writes to the CRM, invalidate or reload deliberately. Reloading the page in one user's requestor refreshes that copy only; other requestors keep their cached version until their interval expires, and node-scoped copies are not automatically refreshed on every node.

Two different mechanisms, often conflated

1. Staleness on the case clipboard. The Complaint's review screen is bound to a copy loaded earlier (on the case page or a section-level page). Nothing re-reads the source unless a reload condition, a refresh action, or the data page's own strategy says to. A refresh can even re-read a stale cache if the interval has not expired.
2. One-time copy into the child. Data propagation to a child case happens once, at creation, and in one direction. The child will never observe a later change unless it references the data page at runtime by ID, or the parent pushes an update to the child - and push is fragile, order-dependent, and leaves the child wrong if the push fails.

Live view or snapshot: decide per use

• If the old address is part of "what the decision was based on" (regulatory, dispute, audit), keep an immutable snapshot and say so: store the captured address with a captured-at timestamp and label it in the UI as "address at time of filing."
• If the address is only used to mail a document or route a visit, look it up live at the moment of use.
• Most claims screens need both: the ID plus a deliberate snapshot for audit, and live data for the operational fields.

Consequences for the child

Do not design the child to hold a propagated copy of anything that can change and that it makes decisions on. Hold the customer ID and reference the data page, with an explicit refresh on the events that matter (address change approved). Then test it: change the address, reopen the complaint and the child, and confirm both behave as designed.

Concrete costs

• A data page is defined for a class. Four classes means four data pages, four sets of data transforms, and four sections - or one class's page silently used for another, which is worse.
• Security is duplicated four times. Access-of-role-to-object entries are per class, so the day one class is missed, the same customer data has a weaker permission set than the others.
• Reporting needs unions across four classes; case-level views have to join them by hand.
• Every fix is made four times, and the fifth case type adds a fifth copy.

Restructure

1. Create one customer data class - Data-Customer or GlobalRetail-Data-Customer - holding the thirty shared properties and the single data page and transforms.
2. Put genuinely case-specific attributes on the case type or its work class, not on a customer class.
3. If a case genuinely needs its own copy of the customer with case-scoped state (a complaint respondent with a case status), model that as a work class linked to Data-Customer by ID, not as a parallel concrete customer class.
4. Use pattern inheritance only where "is-a" is true and you accept that a parent change reaches every child. Reuse by reference is usually what you want here.

Migration reality

Consolidating changes the class of stored data and every rule that names the old class: sections, data transforms, data pages, access matrices, and report definitions. Sequence it as: create the target class and page, repoint rules, backfill and validate data, then retire the old classes. Do not run a big-bang switch without a reconciliation report per class.