---
id: TST-PFM-NOT-079
title: orchestrate request
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js
implements:
  - ATS-PFM-NOT-003-01
  - ATS-PFM-NOT-003-05
  - ATS-PFM-NOT-003-06
  - ATS-PFM-NOT-003-07
  - ATS-PFM-NOT-003-08
  - ATS-PFM-NOT-004-01
  - ATS-PFM-NOT-004-04
  - ATS-PFM-NOT-005-07
  - ATS-PFM-NOT-006-05
  - ATS-PFM-NOT-006-06
  - ATS-PFM-NOT-007-01
  - ATS-PFM-NOT-008-03
  - ATS-PFM-NOT-013-02
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned records in the prepared integration workspaces; seeded workspace
  identities remain shared fixtures.
assertion_bindings:
  - scenario: ATS-PFM-NOT-003-01
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#refuses
        an audience kind the definition does not accept
  - scenario: ATS-PFM-NOT-003-05
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#keeps
        the actor out of the audience unless the producer asks
  - scenario: ATS-PFM-NOT-003-06
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#accepts
        an audience of exactly 200 people and refuses 201 as invalid
  - scenario: ATS-PFM-NOT-003-07
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#drops
        a user of another customer, an invited user and a portal user, recording
        isolation_refused
  - scenario: ATS-PFM-NOT-003-08
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#notifies
        nobody when everyone named is outside the organization, recording
        no_recipients with the refusal
  - scenario: ATS-PFM-NOT-004-01
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#writes
        one instance for the person, rendered in their words, about nothing
  - scenario: ATS-PFM-NOT-004-04
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#redacts
        a url field of the data from the request after it was rendered
  - scenario: ATS-PFM-NOT-005-07
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#makes
        one instance for one occurrence however many requests name it
  - scenario: ATS-PFM-NOT-006-05
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#expires
        a request published after its expiry
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#expires
        a request older than its definition’s expires_after from the instant the
        producer wrote it
  - scenario: ATS-PFM-NOT-006-06
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#gives
        back a request that is not due yet, writing nothing, never processing it
        early
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#processes
        a request whose time has come
  - scenario: ATS-PFM-NOT-007-01
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#writes
        the console delivery delivered at once and records every other supported
        channel as not available until its milestone
  - scenario: ATS-PFM-NOT-008-03
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#recognizes
        a redelivered item by its record, writes nothing more and nudges the
        dispatcher
  - scenario: ATS-PFM-NOT-013-02
    suite: TST-PFM-NOT-079
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#refuses
        a system audience for now, whatever the definition declares
evidence:
  - >-
    services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL with row-level security on, the real orchestrator,
    persistence services, renderer, constraints and policies.
  - >-
    Doubled: the dispatcher nudge (a recorder) and the channel adapter of the
    delivery-work case (a recording adapter, which is the
  - >-
    seam the later milestones fill). Never doubled: the database, the audience
    resolution or the rendering.
---

# orchestrate request

## Verification Boundary

This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway.

## What This Suite Proves

Its cases exercise validate each audience selection; union recipients with exclusions and actor control; enforce the whole-request recipient limit; exclude ineligible and cross-customer users; retain empty-audience outcomes; apply locale fallback and time-zone formatting.

The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file.

## What It Does Not Prove

Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed.

## Real Dependencies and Test Doubles

The notification fixtures use real PostgreSQL and module logic. Queue publication, visibility changes, nudges and installed channel adapters are recorded at their seams when the suite needs them. Signed API contexts replace the authorizer key in API suites.

## Must Not Be Doubled

Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.
