QUICK ANSWER
What are good workflow examples?
Good workflow examples show one durable record moving through explicit states under named actors and server-checked rules. They include the normal path, invalid input, technical retry, waiting, cancellation or correction, partial failure, timeout, verification, and recovery. A reusable example explains which decision changes the record and which provider side effect remains separate.
A useful workflow example does more than arrange boxes. It names the authoritative record, current state, trigger, actor, guard, next state, side effect, retry behavior, exception path, and observable check. That is enough structure to expose gaps before screens make a vague process look finished.
This guide compares ten cross-functional patterns in one consistent format. Download the source pack, choose the nearest job, and replace its policy with your own. The examples are planning artifacts, not universal rules, deployed apps, provider integrations, or substitutes for security, privacy, and operational review.
How to read and adapt a workflow example
Treat the diagram as an index and the state table as the contract. The pack uses a four-pass review so normal behavior, authority, retries, and exceptions remain visible without pretending that every organization follows the same process.
Bound one record and one lifecycle
Name the stable record ID, owner, initial state, terminal states, version, and retention decision. Split notifications, payments, files, provider events, and audit entries into separate records when they can fail or retry independently.
Sources: [workflow-pack], [bpmn-spec]
Write every allowed transition
For each current state, list the trigger, actor, guard, next state, durable effect, and observable verification. Anything not listed is denied by default. Add waiting, cancel, correction, reopen, timeout, and partial-failure transitions before polishing the interface.
Sources: [workflow-pack], [owasp-authorization]
Separate retry identity from record version
Use one stable identity for the same technical attempt and a version check for concurrent human changes. HTTP method semantics can inform transport behavior, but the application still needs its own scoped retry ledger, safe input fingerprint, retention, and conflict rule.
Sources: [workflow-pack], [rfc-9110]
Test the table before implementation handoff
Run a happy path, invalid or unauthorized action, exact retry, changed retry, stale version, partial failure, published smoke, and recovery rehearsal. The expected record and audit counts should reconcile after every case.
Sources: [workflow-pack], [owasp-authorization]
What these examples cover and what they leave open
The examples deliberately stay provider-neutral. They are specific enough to review record behavior, but they leave product, policy, and provider choices with the people who own them.
Included
- Ten named business jobs with 82 state transitions
- Actors, guards, side effects, retry rules, verification checks, and failure paths
- Happy, invalid, retry, and published-smoke prompts for every example
- A blank CSV state-table template plus machine-readable JSON
Not included
- A universal workflow policy or automatic approval decision
- Native email, billing, CRM, inventory, or messaging connectors
- Authentication, authorization, legal, privacy, or compliance approval
- A public deployment or evidence that a provider side effect succeeded
DOWNLOADABLE RESOURCE
Download the workflow examples pack
The ZIP keeps the ten examples, readable field guide, blank state-table CSV, structural validator, and deterministic tests together. Inspect the files first, then adapt a copy rather than changing the reviewed source in place.
Workflow examples and state-table pack
Ten provider-neutral workflow examples for lead intake, content publishing, work orders, client onboarding, inventory, incidents, support, renewals, imports, and releases.
Format: JSON, Markdown, CSV, and Node.js tests in one ZIP archive
Locally reproduced August 1, 2026. SHA-256: c5cce061d9fd55e288d0c12fca48177cea3eced82ec91ffb00d534cff47d7674
Included
- Ten machine-readable workflow examples
- Eighty-two reviewed state transitions
- Readable workflow field guide
- Blank state-table CSV template
- Deterministic validator and graph mutation tests
Verification boundary
The archive, allowlisted files, state references, unique IDs, terminal sinks, nonterminal exits, initial-state reachability, terminal reachability, declared recovery rejoins, retry fields, test prompts, blank CSV, and exception paths were checked locally. Public availability and any adapted production workflow remain separate verification gates.
Ten workflow examples and where each one helps
Each pattern focuses on a different operational failure. The state names are starting points. Replace them when your actual owner, policy, provider, or record boundary differs.
Lead intake and qualification
Use when: An inbound inquiry needs durable capture, human review, and a bounded follow-up decision.
Save the lead before delivery, qualify only against the current record version, and keep notification failure separate from the qualification result.
Structure
- received -> needs-review -> qualified -> follow-up-due -> closed
- follow-up-due -> delivery-failed -> follow-up-due retries delivery without duplicating the lead
Watch for: Do not treat a sent notification, a score, or an inferred label as proof that the lead is qualified or contacted.
Sources: [workflow-pack], [rfc-9110]
Content publishing
Use when: A versioned draft needs editorial review, scheduling, publication, correction, and retirement.
Freeze the reviewed content version so a stale review cannot schedule a changed draft, then preserve every public revision and correction decision.
Structure
- draft -> in-review -> scheduled -> published
- changes-requested, correction-needed, and retired preserve version history
Watch for: A scheduled job is not a published page, and a sitemap row is not verification that the intended revision is public.
Sources: [workflow-pack], [bpmn-spec]
Work order dispatch
Use when: A request must be triaged, assigned, performed, reviewed, and closed by named operators.
Separate request ownership, assignment, progress, blocker, completion evidence, and close decision so a stalled job never appears finished.
Structure
- requested -> triaged -> assigned -> in-progress -> completed -> closed
- blocked retains the assignment; cancel is bounded to work that has not started
Watch for: A preferred time, dispatch note, or worker start event is not a confirmed outcome, completion, or final quote.
Sources: [workflow-pack], [owasp-authorization]
Client onboarding
Use when: A client invitation leads to intake, setup, requests for missing input, and a formal handoff.
Use single-use invitation acceptance, versioned intake, an owned setup checklist, and durable client requests that survive delivery failure.
Structure
- invited -> intake-incomplete -> ready-for-setup -> setup-in-progress -> active
- waiting-on-client stores one request and resumes only after a saved response
Watch for: A hidden link or client-selected ID is not authorization; protect every list, detail, file, update, and export on the server.
Sources: [workflow-pack], [owasp-authorization]
Inventory replenishment
Use when: A stock signal needs review, ordering evidence, partial receipt, reconciliation, and stock posting.
Record received lots with stable IDs and update authoritative stock only after ordered, received, and discrepancy quantities reconcile.
Structure
- signal-created -> review-needed -> order-ready -> ordered -> received -> stock-updated
- partially-received and discrepancy keep mismatched quantities visible
Watch for: Marking an order as placed does not prove payment, delivery, condition, or available stock.
Sources: [workflow-pack], [rfc-9110]
Operational incident response
Use when: A service symptom needs triage, investigation, mitigation, observation, resolution, and follow-up.
Keep one incident identity and ordered timeline across mitigation and regression so a reopen does not split related evidence into duplicate incidents.
Structure
- detected -> triaged -> investigating -> mitigating -> monitoring -> resolved -> closed
- reopened retains the original incident ID and timeline
Watch for: A mitigation action or returning signal is not a final resolution until the planned observation and follow-up gates pass.
Sources: [workflow-pack], [bpmn-spec]
Support request escalation
Use when: A durable request can wait on the customer, wait on another team, escalate, resolve, reopen, and close.
Keep customer communication, internal tasks, routing escalation, and request decisions separate while preserving the original request history.
Structure
- new -> assigned -> resolved -> closed
- waiting-on-customer, waiting-on-team, escalated, and reopened remain explicit
Watch for: Escalation changes responsibility or urgency; it must not silently decide the customer request or expose private content.
Sources: [workflow-pack], [owasp-authorization]
Subscription renewal review
Use when: Provider payment evidence and local product access can succeed or fail independently.
Store verified provider evidence once, apply the local access policy separately, and open reconciliation if the local transition fails.
Structure
- renewal-due -> payment-pending -> provider-evidence-received -> renewed
- reconciliation-needed preserves provider evidence while local access remains unchanged
Watch for: A checkout return page is not payment proof, and a provider status does not choose your local access, grace, or expiry policy.
Sources: [workflow-pack], [rfc-9110]
Data import batch
Use when: Uploaded rows need mapping, preview, validation, commit, row-level results, and resumable recovery.
Freeze the accepted preview, give every source row a stable result identity, and resume after a worker error without repeating completed writes.
Structure
- uploaded -> mapped -> validated -> ready -> committing -> committed
- changes-required and partial-failure retain rejected rows and a resumable cursor
Watch for: Do not auto-merge ambiguous people or company records on a shared name, email, or phone without an explicit uniqueness policy.
Sources: [workflow-pack], [rfc-9110]
Release checklist
Use when: One immutable release candidate needs checks, publication, observation, and a bounded rollback decision.
Bind every check and deployment attempt to the exact build ID, target, rollback candidate, and predeclared kill gate.
Structure
- candidate -> checking -> ready -> publishing -> observing -> released
- blocked, rollback-needed, and rolled-back preserve the candidate evidence
Watch for: A green build does not prove the target is healthy; verify the deployed version and user-facing smoke before observation begins.
Sources: [workflow-pack], [bpmn-spec]
Choose the smallest workflow model that still exposes failure
More states are not automatically better. Add a state only when it changes ownership, allowed actions, waiting behavior, verification, recovery, or what the user needs to understand.
The step can fail after the main record is saved
Choose: Model the side effect as a separate attempt or outbox record with its own identity and retry state.
Tradeoff: You add operational records, but a provider outage no longer loses or repeats the business decision.
Two people can change the same record
Choose: Use expected-version checks for concurrent decisions and keep technical retry identity separate.
Tradeoff: Users must resolve conflicts explicitly, but stale screens cannot overwrite newer work.
A waiting period changes who can act
Choose: Create an explicit waiting state with an owner, timeout rule, and resume transition.
Tradeoff: The table grows, but stalled work becomes measurable and recoverable rather than hiding in notes.
The process is only a checklist with no state-dependent actions
Choose: Keep a checklist instead of inventing a state machine, and give each item an owner and evidence field.
Tradeoff: You lose transition automation, but the model stays honest and easier to maintain.
PICK ONE RECORD
Turn the nearest example into your own state table
Download the pack, replace the fictional actors and rules, and review every exception with the people who own the process. A smaller truthful workflow is a better build brief than a polished diagram with hidden decisions.
Download the workflow packThe ZIP is locally reproduced. Public availability must be verified after deployment.
Explore custom internal toolsUse the internal-tools path when the workflow is private and operator-facing.
Limits of a reusable workflow example
The pack makes review easier; it cannot decide the policy or prove the production environment. Recheck these boundaries before a workflow is exposed to real users or records.
- The fictional states and actors do not establish your legal, regulatory, contractual, safety, or retention policy.
- The pack does not implement authentication, server authorization, provider credentials, signatures, delivery, billing, or external reconciliation.
- Local deterministic tests do not prove a public route, target database, concurrent production behavior, monitoring, backups, or recovery.
- Approval-specific routing, quorum, delegation, separation of duties, and escalation require a separate reviewed policy; they are not inferred from these examples.
Sources and verification record
The same-release pack is the source for the ten examples. Primary standards and security guidance support the notation, authorization, and transport boundaries without turning them into provider or product claims.
[workflow-pack] Playcode:Workflow examples machine-readable source
Checked August 1, 2026. Supports: The locally reviewed ten examples, 82 transitions, tests, retry fields, failure paths, and exact same-release artifact content. Public availability remains unverified until deployment.
[bpmn-spec] Object Management Group:Business Process Model and Notation 2.0.2
Checked August 1, 2026. Supports: Primary process-modeling vocabulary for activities, events, gateways, sequence flows, and process diagrams. The pack does not claim formal BPMN conformance.
[rfc-9110] RFC Editor:RFC 9110, HTTP Semantics section 9.2.2
Checked August 1, 2026. Supports: HTTP method idempotence semantics only. Application retry keys, fingerprints, retention, replay results, and conflicts remain an explicit local design.
Workflow example questions
What should a workflow example include?
Include one authoritative record, stable ID, owner, states, triggers, allowed actors, server-side guards, next states, durable effects, retry behavior, waiting and exception paths, verification checks, retention, and recovery. Keep external provider attempts separate when they can fail independently.
How many states should a workflow have?
Use the fewest states that change ownership, allowed actions, waiting behavior, verification, or recovery. Do not create a new state for every screen label. Do create one when work can pause, fail partially, require correction, reopen, or become terminal under different rules.
What is the difference between a workflow and a checklist?
A checklist tracks items to complete. A workflow controls which actions are allowed from the current record state and who may perform them. If order, authority, retries, or state-dependent actions do not matter, a checklist may be the clearer model.
How do retries work in a workflow?
Give the same technical attempt a scoped identity and safe input fingerprint. An exact retry returns the existing result; changed input under that identity conflicts. Use a separate expected version to protect concurrent human edits. Decide how long retry records live and how downstream effects reconcile.
Can I copy one of these workflows directly into production?
No. Copy it into a review draft, then replace actors, guards, fields, states, timeouts, access rules, providers, retention, monitoring, and recovery with your real policy. Re-run deterministic tests and target-environment smokes before real users or data enter the workflow.
Can Playcode build a custom workflow app?
Playcode can build and run a custom web app from a reviewed workflow brief, including a backend and database where the job needs them. Provider accounts, credentials, policy review, real-user testing, and any regulated or high-risk decision path remain separate responsibilities.
BUILD THE REVIEWED WORKFLOW
Give Playcode the record, states, rules, and tests
Describe the workflow in plain language or paste the completed state table. Playcode can build and run the tailored web app while you keep provider credentials, policy review, and production validation explicit.
Explore internal toolsNo native workflow provider, automatic approval policy, or guaranteed business outcome is claimed.