Submission to Publication

A workflow built around decisions, not platform limitations.

Status In Production · since 2023

Role Design + EngineeringSolo · designed around content manager and creator needs

Context San Antonio ReviewFoundational system · every other component depends on this

Stack

WordPress PHP Gravity Forms GP Nested Forms Gravity Flow Stripe

The workflow we built embeds editorial decisions other platforms don’t have a step for: per-category routing, a permission step before any production work begins, and a gate that prevents publishing anything that hasn’t been signed off twice.

The Design Problem

Content workflows have decisions that generic submission intake platforms don’t model.

Submittable is the standard tool for independent publication intake. It works for the common case. One creator, one piece, one decision: approve or decline. Generic, transactional, fast.

SAR’s editorial process is not that shape. Creators submit multiple pieces in a single session and pay once; content managers decide on each piece individually. Different categories follow different submission norms. Creators routinely submit the same work to multiple publications simultaneously. Many publications require exclusivity, and the production work that happens after acceptance — images, social copy, normalized author records — is expensive enough that producing it before confirming the piece is still ours to run is a bad use of our resources.

None of that fits inside a generic intake tool. The submission workflow isn’t overhead that precedes review work — it’s content management work. Running it on a platform optimized for someone else’s shape means accepting that shape.

The off-the-shelf argument

“Submittable handles 80% of submissions. Use the standard tool. Don’t reinvent intake.”

why we built a custom solution

“Per-category limits, permissions, multi-piece-one-payment, production gating — the parts you’d actually call the content management process.”

What I Designed

Five phases, two approval gates, one parent entry that holds the work.

The workflow spans from a submission to content going live. Five phases, three actors, two gates, where a human decision can end the workflow without producing wasted work downstream. A parent entry holds the creator’s bio, payment, and social details; one to five child entries hold the individual content submissions. Content managers decide on each child independently, while creators pay once.

Five phases. Two approval gates — content manager review and creator permission. No production work begins until both are clear; either can end the workflow.

What I Deliberately Did Not Build

The automations that would have crossed into content decisions or generated unnecessary work.

The workflow is built to gate decisions, not to substitute for them. Each rejection below is a place where automation would have stepped into territory that must remain human, or produced work that may prove unusable.

AI submission scoring

Even with content managers retaining final authority, an AI-generated score would shape what they look at first and how they read it. The artifact creates the problem, not the policy around it. Reading stays human, from the first read.

Auto-acceptance or auto-decline by scoring thresholds

“Quality” in publication work is an act of judgment, not a score above or below a line. Automating the decision would not make the workflow faster, but it would reduce the quality of the decisions. Every accept and decline is a human call.

Asset production before creator permission

Contributors routinely submit the same work to multiple publications at the same time. SAR is fine with simultaneous publication, but many publications require exclusivity. A piece SAR has accepted may already have been claimed by another publication in the interval. Producing assets — image, social copy, normalized author record — before confirming the work is still ours to run wastes effort on content that may not be published. The permission step surfaces that early.

One decision per parent entry

Creators submit one to five pieces per session and pay once; treating the parent as the decision unit would force an all-or-nothing accept/decline across work that a content manager wants to handle individually. The parent-child structure separates the transaction from the decisions: one payment, per-piece judgment.

How It Works

The submission workflow, end to end.

Multi-step submission form

Gravity Forms · GP Nested Forms

Bio, genre, work, payment

A single parent form steps the creator through bio, social, category selection, the category-specific child form, and payment. Conditional logic shows only the child form for the selected category. Each genre has different submission rules that align with how creators submit work in that category.

Parent-child entry architecture

Gravity Forms data model

One transaction, many decisions

A submission creates one parent entry — bio, payment, social, contact — and one to five child entries, each holding a single piece with a unique ID. The parent is the transaction; the children are the units of work. This separation lets the workflow serve two real needs that pull in opposite directions: creators want to submit and pay once, and content managers want to decide on each piece independently. The architecture is the resolution.

Per-category approval workflow

Gravity Flow

Review per child entry

Each child entry routes into a per-category workflow with its own approval steps. Content managers review the piece, then approve or decline. We can restart the workflow from any step, with or without resending notifications. This is necessary because reality is messy (a creator changes their mind, a content manager reconsiders a borderline piece, a piece needs to be pulled back). The workflow accommodates that without breaking.

Permission flow

PHP · email notifications

Confirm before producing

When a child entry is approved, the system emails the creator asking permission to publish. The creator clicks approve or deny via the link in the email. Approve advances the workflow; deny ends it without producing assets.

This step used to be a manual email, but the workflow now automates it. This was one of the structural reasons for building custom rather than configuring an off-the-shelf tool.

Approval-gated post creation

PHP · Gravity Flow hook

Architectural prevention of premature publication

The post creation feed is gated on both approval AND creator permission. The hook fires only when both have been recorded, after which the draft content is created and the downstream production components (author normalization, image creation, social media) can begin their work.

// Defer post creation until BOTH editor approval AND creator permission
// Per-genre approval step IDs: Poetry (144), Prose (152), Art (139)
add_action(‘gravityflow_step_complete’, function($step_id, $entry_id, $form_id, $status) {
  if ($status !== ‘approved’) return;

  $approval_steps = [
    POETRY_FORM => 144,
    PROSE_FORM  => 152,
    ART_FORM    => 139,
  ];
  if (!isset($approval_steps[$form_id])) return;
  if ($step_id !== $approval_steps[$form_id]) return;

  // Both gates: editor approved AND creator granted permission
  $permission = GFAPI::get_field_value($entry_id, ‘creator_permission’);
  if ($permission !== ‘granted’) return;

  GFAPI::send_notifications($form_id, $entry_id, ‘post_creation’);
}, 10, 4);

Result

A workflow shaped by the process, not the platform.

Category-routed paths

Approval gates

Content created before both gates clear

Third-party platforms in the workflow

Preserved

Every acceptance and decline is a human decision
The submitter’s experience is intentional design, not third-party UI
Multi-piece submissions stay one transaction, with per-piece content decisions
Content managers can override or restart the workflow when reality intervenes

Now possible

Per-category submission rules that match how creators actually submit
A permission step that prevents production work on pieces that won’t go live
Architectural prevention of premature publishing is code, not policy
The pattern ports to any approval pipeline handling submissions from multiple actors with oversight, such as ECM, regulatory submissions, content-marketing approval, and multi-stakeholder review

Submission to Publication

Content workflows have decisions that generic submission intake platforms don’t model.

Five phases, two approval gates, one parent entry that holds the work.

The automations that would have crossed into content decisions or generated unnecessary work.

The submission workflow, end to end.

Multi-step submission form

Parent-child entry architecture

Per-category approval workflow

Permission flow

Approval-gated post creation

A workflow shaped by the process, not the platform.

Preserved

Now possible

Part of the SAR system.

Content production & delivery pipeline

Automated content approval workflow

Author normalization

Image creation service

Social media service

Custom theme

RAG-based content search