Customer 360 Data Page That Is Always Stale

The single page is slow because it combines four sources and 40 properties in one load, and it is stale because the refresh strategy is set to 24 hours for data that changes intraday.

I would decompose by use and volatility:

• CustomerSummary: core banking and CRM, about 10 properties needed at case open, read-only, requestor scope, reload if older than 15 minutes. This page is on the critical path to open the case under 2 seconds.
• CustomerCards: cards data, read-only, loaded only when the user opens the cards section, requestor scope, reload if older than 15 minutes or on demand.
• ComplaintHistory: complaints data, read-only, loaded on demand with pagination, not at case open.
• CustomerUpdate: a separate editable data page or case-level embedded property used only when the user edits address or contact fields. It should not be the same page that feeds read-only screens.

Use a data transform to map source responses into each page. Set scope deliberately: requestor for customer-specific data, node or application only for true reference data. Do not use 24-hour refresh for address; use 15 minutes or invalidate after a successful CRM update. The two other case types should consume the smaller summary page, not the 40-property page, which reduces coupling and load.

Do not edit the read-only CustomerSummary data page directly. That page represents a cache of source-system data, and editing it creates a split-brain problem between Pega and CRM.

I would:

• Capture edits in a separate editable data page or a case-level embedded property. The case records what the user intends to change, who requested it, and why.
• Save through a data transform that calls the CRM API, not through an activity that writes directly to the CRM database. The CRM API enforces address validation, duplicate checks, and any regulatory rules.
• Use optimistic locking or a version field from CRM. If another user changed the address while this case was open, the save should fail with a clear reconciliation message rather than overwrite the newer value.
• After a successful save, invalidate or reload CustomerSummary so the next screen shows the new value. Do not wait for the 15-minute TTL.
• Handle CRM errors explicitly: validation error, unavailable, and conflict. Show the user what failed and keep the case in a state where they can retry or route to a data steward.
• If address changes require approval, model an Update Customer case or an approval assignment; do not let a maintenance case silently change master data.

The key is to treat CRM as the system of record and Pega as the orchestrator, with an explicit save contract and cache invalidation.

The failure mode is caused by coupling unrelated sources into one page. Resilience and speed both improve when cards is isolated.

Design:

• Remove cards from the case-open path. CustomerSummary loads only core banking and CRM. Cards loads in its own data page and section when the user needs it.
• Add error handling to the Cards data page: timeout, log the error, return an empty or unavailable state, and show a clear message in the cards section. Do not fail the entire case open.
• Use a short timeout for cards and a circuit-breaker pattern so repeated failures do not consume threads or make every user wait.
• Cache stable card metadata if appropriate, but do not cache volatile balances beyond the stated freshness requirement.
• For the under-2-second target, measure the critical path only: core banking plus CRM, with the minimum property set. Use filtering by customer ID, avoid loading 40 properties, and load history or complaints on demand.
• Add monitoring for each source separately so operations can see that cards is down without declaring the whole case unavailable.

The judgement call is that availability is a per-source concern. A degraded cards section is acceptable; a failed case open is not.