Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.

Server-driven workflow screen design

Status: accepted contract, with implementation expanding by vertical slice. The Contentful form contract, workflow contract, ADR 0004, and ADR 0005 are authoritative.

sequenceDiagram

    participant Author as Content author

    participant CMS as Contentful

    participant Registry as Release registry

    participant UI as React SPA

    participant BFF as BFF

    participant BPM as Camunda

    participant Owner as Business owner

    Author->>CMS: Publish en-US and es-US entries

    Author->>Registry: Request Atlas release activation

    Registry->>CMS: Fetch published dependency graph

    Registry->>Registry: Validate and compile immutable bundle

    Registry->>Registry: Activate validated release for new work

    UI->>BFF: Open case/task screen with session and locale

    BFF->>Owner: Check actor, context, record and pinned release

    BFF->>BPM: Verify current task, assignment and logical screen reference

    BFF->>Registry: Load screen from case's pinned release

    BFF-->>UI: Allowed components, localized copy, data, rules, actions and revisions

    UI->>UI: Render allowlisted components#59; give early validation feedback

    UI->>BFF: Save/submit answers, action and expected revision

    BFF->>Owner: Recheck permission, applicability, validation and idempotency

    Owner->>BPM: Deliver correlated transition through durable command path

    BFF-->>UI: Authoritative record/task outcome or recoverable status

Camunda chooses the kind and state of work: the process/task supplies a stable logical screen reference, transition names, assignment and current state. Contentful supplies the screen's supported elements, order, bilingual text, display conditions and declarative validation. The business owner supplies authorized data and invariants. The BFF is the trust boundary that joins all three into one server-driven screen model. React renders that model from an allowlisted component registry; it does not hardcode a product-specific form switch or execute CMS-authored JavaScript.

A draft or case pins a complete en-US/es-US release when it first persists. Publishing Contentful entries alone does not change Atlas's active release; an explicit activation request validates and compiles the published graph first. Requesting information can select a different logical screen inside that same release. Switching locale changes presentation, not answers, option values, assignment or workflow state. New cases can use a later active release; old cases remain reproducible. The release compiler rejects unsupported components/bindings, missing translations and incompatible contracts before activation.

Client feedback is advisory. On save and submit the BFF re-evaluates the pinned rules, field applicability, answer shape, current revision, authorization and task state. Requiredness can wait until submission; forbidden fields, stale revisions and completed tasks cannot. Domain and security rules remain code-owned even if CMS copy or declarative validation changes. Private files travel through an authorized upload route and the scanner; Contentful receives only a supported document-control definition, never the bytes.

The September 30 boundary amendment uses TypeBox for transport envelopes and the supported CMS-definition vocabulary. Contentful still supplies the pinned field rules. Supported internal calls can use gRPC without changing this screen flow or granting a schema-valid request business authority. The later ADR 0013 selects tRPC over HTTPS for browser SDUI experience calls. Migration evidence remains pending; see the tRPC boundary design.

The generic case and request-for-information loop are delivered as a narrow proof of this pattern. Product-specific intake, claim, benefit, leave and payment screens still require their own tracer-bullet slices and integrated tests; this document does not mark them complete.