Suggested answer

I frame it as: what does the data need to do once it is here?

1. Virtualise when: The dataset is large, changes often, and is read in record context — a customer's full invoice history opened from the Account page. There is no storage cost, no synchronisation lag, and no second copy to reconcile.
2. Virtualisation costs: Callout latency on every access, dependency on the source system's availability, and real limitations: external objects cannot back roll-up summaries, have search and reporting constraints, and behave differently in Apex and declarative automation.
3. Replicate when: The data must feed roll-ups, be filtered and aggregated in reports, drive declarative automation, or remain available when the source is down. Replication buys full native behaviour at the cost of storage, integration complexity, and staleness.
4. The hybrid I usually land on: Virtualise the long tail of detail records, and replicate a small set of aggregates — lifetime value, last order date, open order count — onto the parent record. Users get native reporting on the numbers they actually filter by, and the detail stays where it lives.
5. Decisive question: If someone in the room says 'and we need to report on that across all customers', that is usually the end of the virtualisation option.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.