Skip to content

Contact Form Workflow

Purpose

Define the canonical user workflow for route-level contact pages scaffolded from site intent.

This document covers page interaction behavior. It does not replace the Contact BFF transport contract.

Boundary

  • oves-sites owns:
  • whether a contact page exists
  • the selected contact-form block
  • visible copy and labels
  • behavioral props needed for the contact-page workflow (including whether privacy UI is shown)
  • generated ISR apps own:
  • rendering the registered block
  • wiring the form to contactBffUrl
  • client-side pending, success, and error states
  • route navigation after successful submit
  • the Contact BFF owns:
  • authoritative validation
  • audit stamping
  • rate limiting and anti-spam
  • downstream delivery/workflow integration

Standard Interaction Model

The contact page is a dedicated route-level task page, not a modal.

Users must be able to:

  • enter contact information
  • provide a message
  • submit the form

Omnivoltaic corporate intent (docs/sites/omnivoltaic.md v4.2+): no privacy-policy line, no cancel control — visitors leave via browser back or site chrome. Submit is not gated on a consent checkbox.

Sites that do publish a privacy policy may pass privacyPolicyText / privacyPolicyLink on the block; then consent is required before submit and consents may be sent to the BFF.

The page must not trap the user (standard browser navigation remains available).

Required Workflow Rules

1. Standard Controls

The rendered contact form must use established design-system/site primitives where available.

  • fields use the site-standard form treatment
  • optional privacy consent uses the standard checkbox primitive when site intent includes privacy props
  • the primary action uses the same site CTA pattern used elsewhere on the site

Do not mix bespoke native control styling with a design-system primitive for the same interaction.

If privacyPolicyText and privacyPolicyLink are provided:

  • the consent control is visibly present in resting state
  • the primary submit action is disabled until consent is granted
  • client validation rejects submit if consent is absent

If privacy props are omitted, do not require or send privacy consent.

3. Action Hierarchy

  • Primary: submit contact request (required)

Secondary cancel control is optional per site intent. Omnivoltaic does not use a cancel button.

4. Success Exit

On successful submit:

  • leave the contact page
  • prefer a same-site referrer route if available and distinct from the current page
  • otherwise navigate to the configured fallback route (returnHref)

Do not use raw browser-history back navigation as the canonical rule for route exit.

5. Error Handling

On submit failure:

  • remain on the contact page
  • preserve user-entered values
  • preserve consent state when privacy UI is shown
  • show a concise user-safe error message

Block Prop Expectations

When site intent uses a canonical contact block, props typically include:

  • submitLabel
  • returnHref
  • messageLabel
  • visible field labels/placeholders as needed
  • optional: privacyPolicyText, privacyPolicyLink, privacyPolicyLabel (enables checkbox + BFF consents when set)
  • optional: secondary cancel (not used in omnivoltaic v4.2)

Implementation Rule

Site intent is authoritative. Generated apps must implement the intent, not invent a divergent local variant.