Interaction Portal Composite Latency and Stale Customer Data
A Pega Customer Service 23.1 implementation serves 350 agents in a single interaction portal. The customer composite has six tabs: Summary, Cases, Billing, Orders, Interactions, and Documents. All six data pages are configured with Requestor scope and DoNotReload. The Billing data page calls a REST service that averages 2.8 seconds; Orders calls a mainframe gateway at 5.5 seconds; the other four load in under 400 ms. Median composite render is 9.4 seconds. Agents open Billing on 12% of interactions and Orders on 18%. After a customer calls twice in one day, agents report that the balance shown is from the first call and that a previous caller's open cases appeared in the Cases tab. The business requires balance to be no older than 5 minutes and case list no older than 2 minutes. The performance team will not approve any change that increases median render time.
1. Which data pages would you change, and to what scope and refresh settings, to fix both the stale data and the cross-customer leakage? Justify each choice.
Read the worked answer
Move every customer-specific data page (Summary, Cases, Billing, Orders, Interactions, Documents) from Requestor to Thread scope. Requestor scope is per session, not per customer, and DoNotReload means the page is built once; that explains both the stale balance and the prior caller's cases. Thread scope creates a fresh page for each interaction, so a new call cannot inherit the previous customer's data.
For refresh, use 'Reload once per interaction' for Cases and Interactions so they are built at interaction start but not repeatedly. For Billing, the business requires no older than 5 minutes, so use 'Reload if older than' 5 minutes; 'once per interaction' would be too stale on a long call. Orders can use 'Reload if older than' 10 minutes or defer-load. Do not put customer data in Node scope. Keep only true reference data, such as product catalog, in Node scope with a longer reload interval. Verify with two sequential calls from different numbers in the same portal session.
2. How would you reduce the 9.4-second initial render without violating the freshness rules?
Read the worked answer
Use 'Defer load' on the section includes for Billing and Orders so their data pages load only when the agent opens the tab. Billing is opened on 12% of interactions and costs 2.8 seconds; Orders is opened on 18% and costs 5.5 seconds. Deferring them removes those costs from the initial composite render for the majority of calls.
Keep Summary and Cases in the initial load because agents need them immediately, and set their thread-scoped refresh as above. If the composite framework does not expose defer-load for a tab, load the data page from the tab's on-click action and refresh the section, rather than loading all six at interaction start. Do not 'fix' performance by switching back to Requestor scope or DoNotReload; that reintroduces the correctness defect.
After the change, measure median render with the performance profiler and PAL, and track data page load counts per interaction. Target under 4 seconds initial render, with Billing under 5 minutes old when opened.