---
id: ADR-PFM-OPS-009
title: 'Recently Viewed lists are answered by the query layer, not by the activity store'
product_area: platform
module: operations
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
decision: >-
  Use record queries with each person’s latest visit for Recently Viewed lists, and reserve the activity API
  for raw history.
constrains:
  - SVC-PFM-OPS-audit
  - DOM-PFM-OPS-002
  - WF-PFM-OPS-008
origin: >-
  services-platform:docs/audit-events.md#Where a Recently Viewed list comes from (Andrew retired the
  recent-records endpoint on 2026-10-11)
alternatives:
  - option: A separate recent-records API in Audit
    why_not: It would duplicate record queries and need to reproduce current names and readership.
consequences:
  - Combining contacts and organizations requires the client to merge separate query answers.
  - Records outside current readership disappear from record-based recent lists.
supersedes: []
evidence:
  - 'services-platform at ad3f6a6: docs/audit-events.md; docs/debt/recently-viewed-is-one-dataset-at-a-time.md.'
  - >-
    codex examination 2026-10-23: checked the pinned source anchors, planning references and enforcement
    boundaries; unresolved limits are recorded in module findings.
---

# Recently Viewed lists are answered by the query layer, not by the activity store

## Context

Returning to recent work requires current record names and current authority.

## Decision

Have the query layer join current records to the latest visit for the requesting person. Keep chronological visit history as the separate audit read.

## Alternatives Considered

The former dedicated endpoint duplicated the record-query result and has been removed.

## Consequences

Record ownership controls what can still appear, while clients combine lists spanning record types.