This is week one of the SwarmCraft workflow replacement case-study series.
The pattern we are testing is deliberately narrow: take one workflow surface that usually gets trapped inside a broader automation platform, turn it into a clear build plan, and move the first tickets through a real implementation loop.
For week one, that workflow is an approval workflow for purchase requests. The source-product context is Zapier, the target is an internal web portal, and the business problem is familiar: purchase requests arrive through email and chat, budget codes are checked manually, managers and finance do not share one view of pending approvals, and approved requests can still stall before a purchase task or purchase order is created.
This is not a full procurement-platform replacement. It is a safer custom approval workflow around one repeated decision path.
Zapier's own approval process automation page frames approvals around collecting, routing, tracking, and notifying. That is useful category language, but our question for operator-builders is more specific: what would it take to own this one approval process instead of renting another broad automation surface?
The approval workflow we chose
The scenario is a purchase request approval workflow.
The business approval workflow starts when an employee submits a purchase request. The system needs to check the amount and budget code. A manager can approve requests under $5,000. Finance also needs to approve requests over $5,000. The requester should be notified when a decision is made. After approval, the process should create a purchase task or purchase order. Every decision needs to be timestamped, attributable to a named reviewer, and visible in the audit history.
That gives the approval process automation work a real shape:
- intake for the employee requester
- budget-code validation before the request moves forward
- manager approval for ordinary requests
- finance approval for higher-value requests
- explicit fast-track handling for urgent requests
- requester notifications after approval or rejection
- purchase follow-up after approval
- decision logging across every handoff
The important point is that the workflow approval process already has rules. SwarmCraft does not need to invent the policy. It needs to turn the policy into owned software work.
Why approval workflow automation is a good first case study
Approval workflow automation is a strong week-one target because the operational drag is easy to see.
Something enters the process. Someone needs to approve it. Sometimes another person needs to approve it too. The requester needs to know what happened. The business needs a record of the decision. If any handoff is unclear, the work stops.
That makes a manual approval workflow a good candidate for a narrow replacement. The team is not trying to rebuild email, Slack, ERP supplier records, or finance systems. It is replacing the messy approval surface that sits between those systems.
That boundary matters. If the source of truth for suppliers, budgets, or accounting already exists, the custom workflow app should respect it. SwarmCraft's safe-replacement stance is to replace the narrow workflow surface, not the whole system of record.
If you want the wider software-category context, pair this case study with Best workflow automation software and Why workflow automation software bloat turns the tool into the bottleneck.
What SwarmCraft produced in week one
The first week was about turning the approval workflow into buildable work.
The scenario driver created the project, opened the project board, captured evidence from the browser workflow, and drove the VS Code extension workflow against the experiment workspace. The current board has 32 tickets: 27 todo, 1 doing, 0 checking, 0 reviewing, and 4 done in the captured view.
The size of the board is intentional. A useful custom approval workflow is not just one form and one notification. It needs foundations, authentication, persistence, audit events, reviewer queues, API contracts, approval rules, integration adapters, documentation, CI checks, and production hardening.
The first implementation pass focused on five foundation packets:
| Packet | Purpose | Current evidence |
|---|---|---|
| Create SwarmCraft repo skeleton and workspace layout | Establish app, docs, infra, backup, and package boundaries. | Packet created with implementation notes and checklist progress. |
| Bootstrap web and API application shells | Create runnable React and Node.js shells with clear local entry points. | Web and API shells validated locally. |
| Set up local development services and environment variables | Add Docker Compose, PostgreSQL, environment examples, and health checks. | Docker stack and API health check validated. |
| Initialize PostgreSQL schema and migration framework | Add Flyway migrations, baseline schema, approval request/event tables, and seed data. | Migration workflow validated from scratch. |
| Add starter test and CI build scaffolding | Add unit, integration, browser, accessibility, and CI entry points. | Local unit, integration, browser, and CI commands verified. |
That may look like plumbing, but it is the work that keeps an approval workflow from becoming another spreadsheet with a nicer front end. Approval process automation needs trustworthy state, repeatable validation, and a clear place to extend the workflow rules.
How the VS Code workflow fits
The other week-one goal was to prove that the project board can drive actual development work inside VS Code.
In the extension view, the board becomes a local operating surface for implementation. Tickets are visible in lanes, packet files stay open while work is happening, and the agent update records what changed, what passed, and what still needs review.
That matters for the pragmatic operator-builder. The workflow owner should not have to trust a black box. They should be able to see the ticket, the checklist, the implementation notes, the validation run, and the next review step.
That is also why human review still matters in approval workflow automation. The point is not to delete judgement. The point is to remove the manual chasing around judgement while preserving ownership of the decision.
What operator-builders should take from this
The useful lesson from week one is not "build everything from scratch."
The useful lesson is that a custom approval workflow becomes realistic when the replacement boundary is narrow enough:
- keep the supplier, budget, and accounting records where they belong
- replace the intake and approval surface that operators currently manage by hand
- make the approval rule explicit before writing screens
- give each handoff a visible owner
- write every decision into an audit trail
- treat notifications as a result of workflow state, not as the workflow itself
That is the difference between "automate approval workflow" as a vague promise and a buildable custom approval workflow.
If the team cannot name the trigger, approver, threshold, exception path, and final system update, it is probably too early to automate. If the team can name those things, the workflow is ready to become tickets.
Where this series goes next
Week one established the approval workflow project, the board, and the first implementation foundation.
The next passes can move deeper into the parts readers will recognize from daily operations: authentication, purchase request intake, approval queues, budget-code checks, Slack and email notifications, ERP and supplier lookup adapters, decision history, and production readiness.
We will use these weekly case studies to show the whole SwarmCraft pattern: pick a narrow workflow surface, turn it into an explicit board, build in small packets, validate as we go, and keep the system-of-record boundary visible.
For readers comparing the broader platform decision, Zapier alternatives, Airtable vs custom workflow, and Notion vs custom workflow cover the switching question from different angles. This article is the implementation-led view: what it looks like when one approval workflow starts becoming owned software.