Guides → Form Submission Workflow

Form Submission Workflow

FieldValue
Audiencepublic
Page typereference
Areaworkflows
Updated2026-05-14
What this covers
---
What is this for?
Good use cases
What NOT to use this for
How this connects to other features
Definition
Purpose
Scope
Entry surface
Handoff sequence
Downstream effects

How a visitor's form submission flows — capture, record landing, notification, integration push.

The Form Submission Workflow is the cross-product process that handles a form submission from the moment a visitor clicks Submit on the public site through the moment the form data lands in the admin, fires the configured notifications, and pushes to any wired integrations. This page is the Reference definition.

Form submission workflow — overview
Visitor submits
Validation
+ Blacklist filter
Record landed
Notify + downstream

What is this for?

Read this page when you want the structural definition of the submission-flow path — entry from the public site, the handoff into the admin, the notification fire, and the integration push.

Good use cases

  • You are scoping a form-driven capture workflow.
  • You are explaining to a stakeholder how SGEN handles form data.
  • You hit a "did the form data go anywhere?" question and want the model laid out.

What NOT to use this for

  • Step-by-step form-build procedures — open the relevant Guide.
  • Per-release shipped change — open What's New or Changelog.
  • Per-component capability detail — open the corresponding surface Reference.

How this connects to other features


Definition

The Form Submission Workflow is the cross-product process triggered by a visitor's form submission. It carries the data from the public capture surface through the admin record landing, fires the configured notifications, and pushes to any wired integrations.

The defining property is multi-handoff. A single submission event produces effects across the public surface, SG-Admin, the notification layer, and (often) one or more integrations.

Purpose

The purpose of this page is to define the submission flow as a Reference layer. It explains the entry surface, the handoff sequence, and the downstream effects.

Scope

This page covers the workflow at the Reference level.

The page covers:

  • The entry surface (public site form).
  • The record-landing handoff (the admin → My Forms).
  • The notification fire (Notification Logic).
  • The integration push (where wired).
  • The boundary against form-build procedures.
The page does not cover:
  • Step-by-step form-build — Guides.
  • Per-form-type configuration — SG-Admin Forms module Reference.
  • Per-release shipped change — What's New or Changelog.

Entry surface

Public site form

The visitor fills out the form on the public site and clicks Submit. The submission event fires.

Entry points — where forms appear
Inline form on Page / Post (added via SG-Builder)
Popup form via Popups module
Standalone landing page with form as primary content

Handoff sequence

Handoff 1 — Public site → SG-Admin record

The submission lands as a record in the admin → My Forms. The record carries the form identity, the submitted field values, the visitor metadata (timestamp, source page).

Handoff 2 — the admin → Notification Logic

If the form configuration includes notifications, Notification Logic fires the configured notifications per channel preferences. Operator-facing email or in-app alert reaches the recipient.

Handoff 3 — the admin → Integration push (where wired)

If the form is wired to an integration (CRM, email-marketing system, custom endpoint), the submission also pushes to the connected service. Integration-driven Automation handles the push.

Downstream handoffs — what fires after submit
Forms inbox — record visible to operators
Email notification — to configured recipients
Webhook fire — to integrations endpoint
Attribution attached — source / medium / campaign

Workflow · Form submission

End-to-end flow

Public site

Entry

Submit clicked

Visitor fills form, clicks Submit.

SG-Admin

Handoff 1

Record lands

the admin → My Forms shows new submission.

Notification

Handoff 2

Notify operator

Configured email + in-app alerts fire.

Integration

Handoff 3

Push to CRM

Where wired, integration push runs.

14:32:08 · contact-form submitted · email=visitor@example
14:32:08 · record landed · SG-Admin My Forms #4127
14:32:09 · notification fired · email + in-app to operator
14:32:11 · integration push to CRM · ack received

Downstream effects

Operator visibility

The operator sees the submission in the admin → My Forms and (per notification preferences) in their notification surface.

Visitor confirmation

If the form configuration includes a confirmation email, Email and SMTP transport delivers the confirmation to the visitor.

Audit trail

The submission event records to the platform audit log per Notification Logic / audit pattern.


Constraints and boundaries

This Reference covers the cross-product submission flow.

Use this Reference for:

  • Understanding the multi-handoff submission path.
  • Reasoning about where a submission goes after Submit fires.
  • Routing operators to the correct surface for diagnosis.
Do not use this Reference for:
  • Per-step form build — Guides.
  • Per-form-type configuration — SG-Admin Forms module Reference.
  • Per-release shipped change — What's New or Changelog.

Public boundary

This page is intentionally public-safe.


Examples

Example 1 — Contact form submission flows end-to-end

A visitor submits the contact form. The record lands in the admin → My Forms; the operator gets an email + in-app notification; the submission pushes to the connected CRM. The visitor receives a confirmation email. All four handoffs complete cleanly.

Example 2 — Notification did not arrive

The submission lands in the admin (visible in My Forms). The notification did not arrive. The operator opens this Reference, walks the handoff sequence, identifies that the issue is at Handoff 2 (Notification Logic) rather than at the form itself, and proceeds to the Notification Logic Reference for diagnosis.

Example 3 — Stakeholder asks "where does the data go?"

The platform lead opens this page and walks the stakeholder through the four handoffs. The Reference grounds the conversation in the platform's submission model.


Documentation guidance

Use this page as the structural definition for the form submission flow. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.


Reading order

Open this page when scoping form-driven capture or troubleshooting submission-flow questions.


Related reading


Vocabulary cross-reference

  • Submission event is the moment the visitor clicks Submit.
  • Record landing is the moment the submission becomes a record in the admin.
  • Notification fire is the moment Notification Logic delivers the operator-facing alert.
  • Integration push is the moment (where wired) the submission flows to a connected service.

Maintenance discipline

When the form submission flow changes across releases (new handoff, new integration push surface, new notification rule), update this Reference and log the change in Changelog.

Related reading

Topic
Workflows
Lead and Tracking Workflow
SG-Admin
Notification Logic
Email and SMTP
On this page