Skip to main content

Integrations Operations Workbench

Status​

Implemented as a safe operational workbench. Configuration mutation workflows remain limited to backed APIs and reviewed role rules.

  • SRS references: outbound integrations and operational traceability.
  • Client response references: Phase 1 basic outbound webhook; Jira and other ticketing integrations are Phase 2.
  • ADR references: integration adapter and SecretProvider seams.
  • Task board references: OP-D035, OP-D036, OP-024.

Problem Statement​

Stakeholders need to understand where alerts are delivered, whether delivery is healthy, whether credentials are configured safely, and whether retries or dead-letter states occurred.

Architectural Intent​

The page is an operations workbench, not an integration marketplace. It uses existing API data, role-aware controls, safe copy actions, filters, and detail drilldowns without fake enabled actions.

What Was Implemented​

  • /console/integrations route.
  • Delivery health summary.
  • Destination list with enabled/disabled state and redacted credential posture.
  • Selected destination detail panel.
  • Filters for enabled, disabled, retry scheduled, failed, dead-lettered, and delivered states.
  • Expandable delivery attempt timeline.
  • Copy buttons for safe IDs only.
  • Refresh action that reloads route data.
  • Disabled future actions with honest reasons.

Components Involved​

  • frontend/src/app/console/integrations/page.tsx
  • frontend/src/components/integrations-operations-page.tsx
  • frontend/src/components/operations-workbench.tsx
  • frontend/src/components/delivery-attempt-timeline.tsx

APIs / Events / Schemas​

  • Uses existing integrations read APIs.
  • Does not add or require new backend endpoints.
  • Does not expose secret values or raw destination URLs.

Deployment Notes​

The workbench ships with the frontend. It works with API data and keeps fixture fallback local/demo only.

Security / Tenant Isolation​

  • Auditor role sees read-only inspection only.
  • Operators can view, copy safe references, and refresh.
  • Tenant admins see only safe or disabled configuration affordances unless an API-backed action exists.
  • Secret values and raw endpoint URLs are not rendered.

Validation Steps​

UI Validation​

  1. Open /console/integrations.
  2. Apply each delivery-state filter.
  3. Select a destination and confirm the detail panel updates.
  4. Expand an attempt and confirm only redacted error details are shown.
  5. Sign in or simulate auditor role and confirm read-only notice is visible.

API Validation​

Verify the page uses the existing API client and existing integrations response shapes. No direct scattered fetch calls should be introduced.

Smoke Validation​

npm --prefix frontend test
npm --prefix frontend run typecheck
npm --prefix frontend run build

Known Limitations​

  • No replay button because DLQ replay API is not implemented.
  • No edit/test-destination form unless backed contracts and audits are added.
  • No Jira/Slack/Teams/ServiceNow/Freshdesk/Zendesk/HaloPSA adapters.

Follow-Up Work​

  • Define operator action API contracts.
  • Add DLQ replay UI only after backend replay contract exists.
  • Add external ticketing adapters in Phase 2.

Acceptance Criteria Mapping​

Acceptance criterionEvidence
Page is useful for PMO review/console/integrations
Retry/dead-letter state visibleDelivery attempt timeline
No secrets or URLs leakFrontend tests and code review
No fake actionsDisabled action hints and API gap docs