Skip to content

Contact Form Workflow

Purpose

Define the standard user workflow for a site contact page rendered by ISR apps, before promoting the behavior into oves-sites intent/contracts.

This document is an implementation contract for dirac-uxi-isr, not the long-term source of truth. Once confirmed, the behavioral props and expectations here should be moved into oves-sites.

Scope

This workflow applies to a dedicated contact page route such as /contact using ContactFormCentered or its successor canonical contact block.

This workflow does not define:

  • the visual brand tokens
  • the Contact BFF transport contract
  • the existence of the contact page route itself

Those belong to theme resources and oves-sites contracts.

Standard Interaction Model

The contact page is a focused route-level form, not a modal.

Users must be able to:

  • enter contact information
  • provide a freeform message
  • explicitly grant privacy consent
  • submit the request
  • leave the form without submitting

The page must not trap the user.

Required UX Rules

1. Standard Controls Only

All form controls must use established system primitives where they exist.

  • text inputs and textarea should use the standard site field treatment
  • consent should use the standard TWP/Catalyst checkbox primitive
  • the primary action should use the same site CTA pattern used elsewhere on the site

Do not mix custom-styled native controls with Headless/TWP primitives for the same interaction.

2. Field Model

The current contact form supports:

  • first name
  • last name
  • company
  • email
  • phone
  • message
  • privacy consent

Current behavioral rule:

  • email is required
  • privacy consent is required
  • other fields are optional unless site intent later tightens them

The submit button must not be actionable until privacy consent is granted.

Required behavior:

  • consent control is visible in resting state
  • checked state is visibly distinct
  • submit button is disabled until consent is granted
  • client-side validation must still reject submit attempts if consent is absent

4. Action Hierarchy

The page must provide two explicit actions:

  • primary: submit contact request
  • secondary: cancel and leave the page

The primary action uses the site CTA pattern.

The secondary action uses the site secondary-link pattern or a future explicit secondary-button site pattern if one is defined.

5. Submit Behavior

On submit:

  1. validate required client-side inputs
  2. submit the durable contact payload to contactBffUrl
  3. show submitting state on the primary action
  4. prevent duplicate submissions during the request

The ISR app owns:

  • request serialization
  • pending state
  • user-safe error display
  • success navigation

The Contact BFF owns authoritative validation and downstream processing.

6. Success Behavior

On successful submit:

  • the contact page should exit
  • if browser history exists, return to the previous page
  • if browser history does not exist, navigate to a configured fallback route

This treats the contact page as a task page. Once the task succeeds, the user returns to browsing context rather than remaining on a completed form.

7. Cancel Behavior

Cancel must use the same exit logic as success:

  • if browser history exists, return to the previous page
  • otherwise navigate to a configured fallback route

Cancel must not submit any form data.

8. Error Behavior

On submit failure:

  • remain on the contact page
  • preserve user-entered values
  • show a concise user-safe error message
  • keep the consent state intact

The form must not reset on failure.

Current Local Prop Needs

These props should exist at the block contract layer once this workflow is promoted upstream:

  • submitLabel
  • cancelLabel
  • returnHref
  • privacyPolicyText
  • privacyPolicyLink
  • privacyPolicyLabel
  • field labels and placeholders that are intended to vary by site

Until oves-sites is updated, ISR may carry temporary local defaults. Those defaults should be treated as transitional only.

Implementation Rule

If a team changes contact-form workflow in ISR, they must not stop at a local patch if the behavior is intended to be standard.

The required follow-through is:

  1. confirm the behavior locally
  2. promote the behavior into oves-sites shared resources/contracts
  3. update scaffold generation or intent translation
  4. remove transitional local defaults where intent should supply values

Immediate Next Promotion Work

Once the current Omnivoltaic contact flow is accepted, promote these into oves-sites:

  • cancel action label
  • return/fallback route for contact page exit
  • explicit consent and submit workflow expectations
  • canonical contact block behavioral contract