Workflow Patterns

Workflow Pattern Studies

Reusable workflow guidance organized around user jobs: data surfaces, form processes, CRUD loops, admin composition, and navigation.

Each study names the job it solves, the components that compose it, the states it must handle, responsive behavior, and what would make it promotable.

§01

Study catalogue

Search by title, group, status, tag, state, anatomy, responsive behavior, or promotion criteria. The rail keeps workflow groups visible while the catalogue stays focused on design-system use.

5 of 5 studies

Studies describe reusable workflow jobs before promotion.

  • Studynavigation

    Workflow pattern index

    A searchable index for public workflow studies, grouped by the jobs designers and engineers need to solve.

    Anatomy

    • Header that names the section purpose.
    • Search field with durable query support.
    • Grouped rail for workflow families.
    • Study cards with status, anatomy, states, and promotion criteria.

    Responsive Behavior

    • Rail moves below the search and results on narrow screens.
    • Cards keep metadata and criteria in a single readable column.

    States

    empty searchmulti-term searchgrouped navigation

    Tags

    cataloguenavigationleft-railsearchindex

    Promotion Criteria

    • Every study page has job, composition, states, responsive behavior, and promotion criteria.
    • Public navigation reads as design-system documentation.
    • Search covers titles, groups, tags, states, and criteria.

    Evidence

    • Catalogue architecture proof keeps workflow pages composition-only.
    • Search behavior is covered in the reusable catalogue organism.
    • Study metadata is serializable at the route boundary.

    Promotion Readiness

    Study only

    Useful as the public index, but not a reusable navigation pattern yet.

    Blockers

    • Needs repeated downstream pull outside the workflow studies section.
    • Needs component-tier cross-links before canonical promotion.

    Next evidence: Prove the catalogue anatomy against another design-system index route.

    Next Study

    Add cross-links from component tiers once repeated workflow anatomy stabilizes.

  • Candidatedata

    Tables and row operations

    Helps operators scan dense row sets, select items, filter work, and act on rows without losing table context.

    Anatomy

    • Metric summary for the current row set.
    • Searchable, sortable, paginated DataTable.
    • Bulk action toolbar and row selection.
    • Side readout for selected or recent actions.

    Responsive Behavior

    • Table keeps horizontal scrolling inside the study area.
    • Readout stacks below the table when there is not enough width.
    • Compact table variant supports side panels and dense review surfaces.

    States

    default rowsfiltered rowsselected rowsloadingemptycompact

    Tags

    tablesdata-tablesortingpaginationbulk-actionsempty-state

    Promotion Criteria

    • Selection, bulk actions, loading, and empty states are covered by focused tests.
    • Contracts accept serializable row data and callback props.
    • Responsive overflow is contained at mobile width.

    Evidence

    • DataTable filtering proof covers client search, emitted search changes, and manual filtering boundaries.
    • DataTableWorkflowStudy behavior proof covers selection and table terminal states.
    • The public study page passes only serializable row fixtures into the reusable organism.
    • DRMG Sales CRM contacts proves production table view, server search, status filter, count copy, reset path, and mobile horizontal overflow.

    Promotion Readiness

    Candidate ready

    Production CRM contacts now pulls the table anatomy through a server-driven route and focused mobile overflow proof.

    Blockers

      Next evidence: Before canonical promotion, repeat the same table anatomy on a second production row-operation surface.

      Next Study

      Compare the same table anatomy against a second production row-operation route.

    • Candidateforms

      Action form process

      Shows how a form moves from schema shape to named controls, validation, pending state, and visible result.

      Anatomy

      • Process checklist with required and enhancement gates.
      • FormShell with named controls and field-level validation.
      • Primary action with pending affordance.
      • Receipt panel for submission outcome.

      Responsive Behavior

      • Form and receipt panel stack on small screens.
      • Controls keep labels, help text, and errors adjacent to their fields.

      States

      idleinvalidpendingsuccessreset

      Tags

      formsserver-actionsvalidationchecklistui-formsprocess

      Promotion Criteria

      • The pattern works with progressive action handoff.
      • Validation, pending, success, and reset states are visible.
      • The form contract uses stable names and typed values.

      Evidence

      • FormShell proof covers native POST, noValidate, data-slot, and hydrated submit interception.
      • ActionFormProcessStudy proof covers named controls, invalid validation, reset, and receipt behavior.
      • The public study page passes typed serializable options and default values.
      • DRMG Sales CRM contacts proves blank create validation, create/edit server-action binding, pending state, success navigation, and visible submit errors.

      Promotion Readiness

      Candidate ready

      Production CRM contacts now pulls the form process through real create/edit server-action boundaries and visible result states.

      Blockers

        Next evidence: Before canonical promotion, prove the same form-process contract on a second server-action form with returned field or action errors.

        Next Study

        Exercise the form process through a second production server-action route.

      • Candidatecrud

        Contact CRUD workflow

        Combines a list, detail panel, create/edit form, delete actions, and mutation receipts into one loop.

        Anatomy

        • Searchable CRUDTable with row actions.
        • Detail panel for selected entity.
        • Create and edit form sharing the same field contract.
        • Mutation receipt for create, update, and delete outcomes.

        Responsive Behavior

        • List and detail panel collapse into a vertical workflow.
        • Table overflow remains contained inside the content column.

        States

        listdetailcreateeditdeletebulk deleteempty result

        Tags

        crudcontactslist-detailcreateeditmutation-cycle

        Promotion Criteria

        • The mutation loop is proven against a real RSC and action route.
        • CRUD controls are accessible and keyboard reachable.
        • Create, edit, delete, and empty states have focused tests.

        Evidence

        • CrudWorkflowStudy proof covers native form names, invalid create blocking, mutation callbacks, delete, and stale search clearing.
        • CRUD workflow route data is serializable and remains app-page owned.
        • The reusable organism keeps list, detail, create, edit, delete, and receipts in one tested loop.
        • DRMG Sales CRM contacts proves production create validation, create success, edit save, view toggle, delete action presence, and keyboard-driven form entry.

        Promotion Readiness

        Candidate ready

        Production CRM contacts now pulls the CRUD loop through RSC route composition, app-client CRM presentation, and authenticated browser checks.

        Blockers

          Next evidence: Before canonical promotion, repeat the mutation loop on another app-client workflow and add full destructive confirmation evidence.

          Next Study

          Run the same loop against a second app-client workflow before canonical promotion.

        • Dogfoodadmin

          Admin dashboard composition

          Defines a dense admin layout where metrics establish context, a table island owns interaction, and status panels expose operational risk.

          Anatomy

          • MetricSummaryGrid for overview counts.
          • DataTable for operational surfaces.
          • Selected-surface panel for row context.
          • Permission and unavailable-state placement.

          Responsive Behavior

          • Metrics wrap before the table section.
          • Table and side panel stack below desktop width.
          • Status and permission panels remain adjacent to the affected workflow.

          States

          healthywatchblockedpermission deniedfiltered table

          Tags

          admindashboardmetricsrscclient-islandstatus

          Promotion Criteria

          • Server composition owns data assembly and passes serializable rows.
          • Client table island receives narrow callback contracts.
          • Permission and unavailable states are part of the page contract.

          Evidence

          • AdminDashboardStudy proof covers metric context, table interaction, permission state, and status panels.
          • Composition rules document RSC-owned data assembly and client-island boundaries.
          • The public study page passes serializable rows and rules into the reusable organism.

          Promotion Readiness

          Candidate blocked

          The composition model is documented, but it needs a second admin surface before extracting a shared block.

          Blockers

          • Needs comparison across at least two real admin routes.
          • Needs production permission and unavailable-state evidence.

          Next evidence: Capture two production admin route proofs with permission, unavailable, metric, and table states.

          Next Study

          Compare this dashboard anatomy across two admin surfaces before extracting a shared block.