THE RELEASE FIELD GUIDE

A better publish starts
with a clear checklist.

Turn an approved idea into a release you can explain. Use six practical checkpoints for the content, the people, the destination, and the way back.

Start the checklist Read the full workflow guide
PUBLISHAPI.COM / FIELD NOTESCHECK.
REVIEW.
RELEASE.

Content · Approval · Destination
Delivery · Verification · Recovery

KEEP THE HUMAN IN THE LOOP ↗
BEFORE THE FIRST REQUEST

Agree on what “done” means.

A successful request, an approved draft, and a page a reader can open are different outcomes. Decide which evidence your team needs at each step.

This checklist is a suggested working method, not a platform-specific certification. Apply it to your own source system and authorized destination. Start with a single representative story, keep the approved revision visible, and write down unresolved decisions before increasing the number of channels or automating more of the process.

THE SOURCE

Make the content reviewable.

Choose the exact source record you intend to release. Identify its revision, title, body format, excerpt, images, and canonical destination. Keep evidence for factual statements with the working draft rather than expecting the reviewer to reconstruct it from scattered messages.

  • Compare names, figures, dates, and quotations with the approved evidence.
  • Check that the title and excerpt represent the complete article rather than promising something it does not explain.
  • Confirm that image permissions and descriptive text are ready for the intended publication.

Leave this step with: one identifiable content revision, its supporting material, and a short list of anything that remains unresolved.

Define a usable content contract ↗
THE DECISION

Attach approval to the revision.

Name the editor or role that can approve publication. Keep that permission separate from text generation, formatting, and file upload. A candidate draft can be structurally valid while still needing a factual correction or a clearer explanation.

  • Review substance first, then readability and presentation.
  • Associate the approval with the exact version that passed review.
  • Require renewed review for a meaningful change after approval.

Leave this step with: an explicit release decision, its scope, and a record of which content was approved. Unanswered questions remain visible instead of being converted into stronger wording.

Build the human review gate ↗
THE PREVIEW

Inspect the destination version.

Map the approved source to the destination’s actual fields and render a preview. Check the complete presentation, including surrounding navigation and related content. A website post, a newsletter, and a social adaptation may need different wording and separate approval.

  • Confirm the intended destination account, site, or document root.
  • Inspect headings, links, captions, image crops, and narrow-screen wrapping.
  • Check whether the destination holds a draft, a scheduled item, or an already-public record.

Leave this step with: a preview tied to the source revision and a clear mapping to the intended remote record or static release.

Compare CMS and static-site workflows ↗
THE HANDOFF

Plan for an uncertain result.

Prepare an operation record before delivery. Keep the source identity and destination identity together, and decide how an operator will distinguish an unfinished operation from one that completed without a saved acknowledgement.

  • Rehearse duplicate delivery without creating duplicate intended publications.
  • Separate invalid content, missing permission, and temporary transport failures.
  • Define what should happen when an older revision arrives after a newer release.

Leave this step with: a bounded retry policy and a reconciliation path. Your job runner should report uncertainty honestly rather than treating every missing response as permission to create another record.

Make retries and reconciliation explicit ↗
THE READER

Verify what people can actually read.

Open the public result without relying on an editor’s authenticated session. Match it to the approved revision. For a static release, inspect the pages and their assets as one set. For a feed, check the item identity and the canonical article it references.

  • Follow the page’s internal links and inspect the intended image files.
  • Compare the visible title, excerpt, publication date, and sharing metadata.
  • Check each distribution channel independently rather than inferring success from the primary website.

Leave this step with: recorded evidence of the intended reader-facing result and a list of any destination that still needs attention.

Check the feed as well as the page ↗
THE WAY BACK

Make a correction possible.

Preserve the accepted content, relevant destination identifiers, and the previous usable release when your deployment process supports it. Name who can stop a pending operation, approve a correction, or restore the earlier static output.

  • Rehearse a correction against the existing publication identity.
  • Confirm who can revoke or replace the publishing identity.
  • Separate a website edit from a decision to send another message.

Leave this step with: a recovery note another operator can follow. Protect the working records and avoid placing credentials, private source material, or internal logs in publicly served files.

Review publishing identities and permissions ↗
PUT THE CHECKLIST IN CONTEXT

Choose a path. Keep the decisions clear.

Explore the field notes for your CMS, content format, delivery channel, or hosting workflow.

Explore all publishing topics