Receive a provisioning alert and review granted customer History

Story

Inspect a provisioning outcome in operations Slack and investigate customer notices with an active access grant.

Operational delivery and customer support are separate parts of this journey. Slack configuration controls the alert path, while an active access grant controls customer History. The provider-configured acceptance path remains a recorded proof gap.

Verification Boundary

The structured steps and assertions carry their own provenance and sources. Test references describe inspected assertions at the pinned commits; this examination does not claim a fresh provider or browser execution.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Goal: Inspect a provisioning outcome in operations Slack and investigate customer notices with an active access grant.
Screens: /hq/tenants/hq/jobs/{job_kind}/{job_id}/hq/notifications
Intent sources: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scope

Steps

#	Surface	Action	Capability	Expected	Provenance
1	`/hq/tenants`	A Rhythm administrator starts customer workspace provisioning in HQ.	`CAP-PFM-NOT-013`	Completion or failure publishes the corresponding operational alert.	documented services-platform:docs/notifications.md#9. Producers
2	`slack chat.postMessage`	The Rhythm bot sends the alert to its operations Slack channel.	`CAP-PFM-NOT-013`	A single message describes the outcome, includes a failure reason when applicable and offers Open job.	test react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts#NT-ACC-0150
3	`/hq/jobs/{job_kind}/{job_id}`	HQ staff follow Open job.	`CAP-PFM-NOT-013`	HQ displays the provisioning job.	test services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#links the Open job button to the job page on the console’s origin
4	`/hq/notifications`	With an active customer access grant, staff select that customer's notification History.	`CAP-PFM-NOT-012`	The page returns the same history available to the customer administrator.	test react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0100.spec.ts#NT-ACC-0100

Alternate and Failure Paths

Path	From step	Condition	Path taken	Outcome	Provenance
failure	2	This environment has no configured Slack bot secret.	Delivery records an unconfigured skip and one warning.	No Slack message is sent, and missing configuration does not crash processing.	test services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#skips the delivery channel_unconfigured, posting nothing, when there is no secret
failure	4	HQ staff lack an active customer access grant.	History access rejects the request without returning customer records.	The customer history remains unavailable.	test services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused without an active staff access grant, naming nothing of the tenant

Assertions

Id	Statement	Provenance
`01`	The provisioning outcome creates an operations Slack message and job destination without appearing in customer History.	test react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts#NT-ACC-0150
`02`	HQ access to customer notification history requires an active grant for that customer workspace.	test services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is answered with an active grant into the tenant, the same page its administrator reads

End-to-end policy: optional: Slack needs adapter and provider verification rather than browser observation. HQ history reads have API grant evidence, while configured provider proof remains incomplete.

Planning

Receive a provisioning alert and review granted customer History ​

Story ​

Verification Boundary ​