Your account
HOL-D082Story implementation: Planned

Inspect approved integrations and their health

operations · Proposed launch phase 1

Start from Home

Review as Platform administrator · Full workflow planned

User story

As a platform administrator, I want to inspect approved integration status and safely handle a failed connection so the team understands what is connected and who must resolve it.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • Show the agreed integration inventory, owning organization/environment, configured-versus-simulated state and last successful check or sanitized error.
  • Distinguish a proposed connector, configured credentials, healthy connection and actually synchronized data; a status card alone does not establish a working integration.
  • Provide a safe status check or retry only for an approved assigned capability, with bounded scope and a clear result.
  • Connecting/disconnecting a provider, OAuth grants, credential changes, spending and live-data movement require separate approval. Display no secret or sensitive provider payload.
  • Approved integrations, ownership and operational escalation remain decisions; no provider is connected and no backend integration is implemented by this story definition.

What to check in the demo

Follow these steps from the role’s landing page through navigation and feature checks.

Review as

Platform administrator

Start here: Home

Choose the Robin Park dummy account and open its assigned Platform administrator Home without a password or authenticator prompt. This dev-only Home review does not verify MFA or unlock protected staff actions. Use your own provisioned staff account and authenticator when reviewing those actions.

Navigation from sign-in

  1. 01Open the fictional Platform administrator account through the connected sign-in service. Seeded Home review opens directly. Real HOL staff access and protected actions require an authenticator check.
  2. 02Start on Platform administrator Home and open Features + permissions. There is no integration-management screen yet; Product + community health is not integration configuration.

Feature checks start here

Inspect approved integrations and their health · Full workflow planned

Planned full workflow. Existing workspace samples, where present, demonstrate only isolated controls. Backend implementation is on hold; no completed end-to-end outcome or stakeholder approval is claimed.

  1. 03Current UI review: follow the navigation as far as the explicitly available screen; the complete feature below is not built. Stop when the named control is absent.
  2. 04Planned acceptance — Review which integrations are proposed, configured or simulated and their intended owner/environment.
  3. 05Planned acceptance — Once an approved inventory UI exists, inspect a healthy and failed synthetic status with sanitized detail and a named next step.
  4. 06Planned acceptance — Run only an authorized safe status-check/retry example; distinguish queued, successful and failed outcomes.
  5. 07Planned acceptance — Confirm that status viewing does not connect a provider, reveal a secret or move production data.

Backend work for this feature

Requirements only · Backend implementation on hold

What needs to be supported

  • Persist provider/integration identifier, organization/environment, approved scope, owner, configuration reference, last check and sanitized health outcome; never store raw secrets in public records.
  • Resolve secrets through approved secure configuration; enforce separately assigned status/check/manage capabilities and organization/environment isolation.
  • Define a bounded idempotent health/retry job with timeout/backoff and audit history; prohibit arbitrary URLs, broad exports and cross-environment writes.
  • Prepare separate trusted consent/connection and data-contract requirements per selected provider, including failure recovery and disconnect semantics; do not execute them while backend implementation is held.
  • Verify sanitized errors, revoked/expired authorization, duplicate retries and unavailable providers without logging credentials or claiming that a status check synchronized data.

How to verify when implementation is approved

  1. Test inventory/status reads for assigned and unassigned accounts and confirm no credential values or provider-sensitive payloads appear.
  2. Simulate healthy, failed, timed-out and revoked states; retry twice and verify one bounded job and accurate result/history.
  3. Verify environment separation and denial of arbitrary endpoint checks, provider connection and data writes without the separate capability/approval.

Before this can work

  • Choose the Robin Park dummy account and open its assigned Platform administrator Home without a password or authenticator prompt. This dev-only Home review does not verify MFA or unlock protected staff actions. Use your own provisioned staff account and authenticator when reviewing those actions.
  • Use fictional role-preview records. Frontend prototypes may simulate the workflow; no backend implementation or real service operation is authorized.

Connected stories