---
id: CAP-PFM-NOT-011
title: Review workspace notification activity
feature: FEAT-PFM-NOT-04
product_area: platform
module: notifications
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
supersedes:
  - NT-ACC-0100
  - PLAT-M23-S04
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
intent_sources:
  - 'services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scope'
  - >-
    services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#3. How it
    works for the user
  - >-
    services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S04
  - >-
    services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S12
purpose: >-
  Administrators can inspect whom the workspace notified and why requests
  succeeded or produced no notices.
outcomes:
  - >-
    Administrators inspect notification activity within authorized workspace
    scope.
  - 'History distinguishes requests, recipient instances and channel deliveries.'
concepts:
  - CON-PFM-NOT-003
actors:
  - ACT-PFM-028
surfaces:
  - console
  - api
preconditions: []
postconditions: []
permissions:
  - key: platform.notifications.manage
    where_checked: api
    scope: tenant
  - key: platform.notifications.manage
    where_checked: console
    scope: tenant
rules:
  - id: BR-CAP-PFM-NOT-011-01
    statement: >-
      Workspace History, request lists and diagnostic chains require
      notification-management permission, included in Administrator; Personal
      inbox permission alone is insufficient.
    kind: permission
    enforced_at:
      - api
      - console
    must_prove: true
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses
      History and the chain to a caller with only platform.notifications.use
    origin: >-
      services-platform:docs/milestones/PLAT-M23-notifications-core-and-in-app.md#D2
  - id: BR-CAP-PFM-NOT-011-02
    statement: >-
      History lists newest-first notices with recipient, request and per-channel
      delivery summaries; Filters cover recipient, definition, category,
      channel, status and since; paging can cross monthly partitions; invalid
      categories and statuses are rejected.
    kind: validation
    enforced_at:
      - api
      - service
    must_prove: true
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#lists
      every person’s notifications newest first with the person and the request
    origin: none
  - id: BR-CAP-PFM-NOT-011-03
    statement: >-
      Request history includes requests with and without resulting notices,
      their notice counts and outcomes including isolation, invalidity and
      cancellation; Outcome, definition and since filters apply in newest-first
      order.
    kind: policy
    enforced_at:
      - api
      - service
    must_prove: true
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#lists
      a request that dropped a named person, one that was refused as invalid and
      one that was heard, and no other tenant’s
    origin: none
  - id: BR-CAP-PFM-NOT-011-04
    statement: >-
      Diagnostic detail connects requests to notices and their explanations and
      deliveries, notices to explanations and deliveries, and deliveries to
      events, notices and requests; a problem-free request returns an empty
      problems list.
    kind: policy
    enforced_at:
      - api
      - service
    must_prove: true
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#carries
      the why and the deliveries of each notification on the request, as the
      notification’s own chain does
    origin: none
  - id: BR-CAP-PFM-NOT-011-05
    statement: >-
      History supplies the latest contributing request's retained data, with
      declared links redacted, so the console can identify responsibility scope.
    kind: policy
    enforced_at:
      - service
    must_prove: false
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#answers
      the data of the newest request a notification folded, one read for the
      page
    origin: none
  - id: BR-CAP-PFM-NOT-011-06
    statement: >-
      History and diagnostic lookups remain workspace-local; unknown identifiers
      and another workspace's records are not found.
    kind: invariant
    enforced_at:
      - service
      - database
    must_prove: true
    provenance: test
    source: >-
      services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js#shows
      nothing of another tenant
    origin: >-
      services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S04
  - id: BR-CAP-PFM-NOT-011-07
    statement: >-
      The History screen resolves recipient names, provides a recipient filter
      and request view, and opens a diagnostic chain from a row; it offers no
      settings editing in this release.
    kind: policy
    enforced_at:
      - console
    must_prove: false
    provenance: test
    source: >-
      react-console:components/notifications/__tests__/notifications.test.tsx#lists
      the organization's notifications with status and reason, naming the person
      from the lookup
    origin: none
  - id: BR-CAP-PFM-NOT-011-08
    statement: >-
      The intended delivery table explains unused channels with the same reasons
      and milestone names shown in the personal explanation sheet.
    kind: policy
    enforced_at:
      - console
    must_prove: true
    provenance: documented
    source: >-
      services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#9.
      Acceptance scenarios
    origin: >-
      services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S12
    note: >-
      Fails at the pinned commit (the recorded defect, open): the table displays
      the reason without its milestone.
scenarios:
  - id: SC-CAP-PFM-NOT-011-01
    given: >-
      Jane's assignment and ending have notices, and an outsider-only request
      produced none.
    when: An administrator inspects History and Requests.
    then: >-
      The administrator finds Jane's item states and the empty request outcome
      and can inspect their diagnostic links.
    provenance: test
    source: >-
      react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0101.spec.ts#NT-ACC-0101
edge_cases: []
constraints: []
depends_on:
  - CAP-PFM-NOT-002
  - CAP-PFM-NOT-003
related:
  - CAP-PFM-NOT-010
  - CAP-PFM-NOT-012
journeys:
  - JNY-PFM-NOT-002
  - JNY-PFM-NOT-003
open_questions: []
evidence:
  - >-
    Pinned evidence inventory 1:
    services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md;
    services-platform:docs/milestones/PLAT-M23-notifications-core-and-in-app.md;
    react-console:components/notifications/__tests__/notifications.test.tsx
  - >-
    Pinned evidence inventory 2:
    services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js;
    services-platform:modules/notifications/tests/integration/services/centre/notification-centre.integration.spec.js;
    react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0101.spec.ts
controls: [TC-AVL-005, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-DAT-001, TC-DAT-002, TC-DAT-003, TC-LOG-002, TC-LOG-003, TC-LOG-005, TC-PI-001, TC-PI-003, TC-PI-005, TC-PRV-001, TC-PRV-002, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-VEN-001, TC-VEN-002, TC-VEN-003]
---

# Review workspace notification activity

## Purpose

Administrators can inspect whom the workspace notified and why requests succeeded or produced no notices.

## How It Works

An administrator opens workspace notification History with management permission. The list combines recipients, requests and channel summaries. Filters locate relevant activity, and paging can continue across monthly partitions. A separate request view includes invalid or empty-audience submissions. Opening a row follows the chain between requests, notices, deliveries and events. Returned data retains scope information while link values are redacted. All reads remain inside the selected workspace. The intended skipped-channel milestone wording still has a recorded console defect.

The rule rows define this outcome; the acceptance set identifies existing proof and proposed checks. Implementation evidence alone does not approve the observed details.

## Relationships

Committed publication supplies the requests processed by this outcome.

Recipient selection supplies the eligible people and their audience explanations.
