Turn recruiting demand into a governed capacity decision.
A synthetic n8n workflow that makes the operating conversation explicit:
validate the request, surface the capacity tradeoff, name the human
decision-maker, assign SLA ownership, and give leaders a weekly view of
what needs intervention.
Portfolio demonstration only. Inactive and synthetic by design. No live ATS, HRIS,
Slack, email, candidate, or employer data; no external sends or durable writes; no automated hiring
decisions.
Operating design · decision logic · control boundaries
Status
Inactive synthetic demonstration
Platform
n8n · 27 nodes · two manual demo paths
Evidence
15/15 artifact checks · three captured views
The operating problem
Priority enters the system. The tradeoff often stays invisible.
Recruiting teams routinely receive requests labeled urgent without a transparent view of
capacity, service-level risk, or who owns the decision to displace existing work. The result is
predictable: every requisition looks equally important, commitments drift, and leaders learn
about constraints after delivery is already at risk.
I designed this workflow to make those decisions visible before work is silently absorbed. The
automation prepares the evidence and records the operating context; a named human remains
accountable for the consequential decision.
Operating design
Five stages from intake to executive visibility.
The workflow is deliberately legible on one canvas. Exceptions sit beneath the decision they belong
to, and the weekly leadership branch reuses the same operating model.
01
Intake
Load a structured synthetic request and establish a traceable requisition ID.
02
Validation and safeguards
Normalize required fields, reject invalid intake, and expose duplicate-ID handling.
03
Capacity recommendation
Use an embedded synthetic snapshot to make the assignment recommendation and constraint visible.
04
Human decision gate
Prepare an approval packet, pause for a named approver, and record decision, approver, and reason.
05
SLA and executive visibility
Draft the operating record, SLA ownership, and a leadership brief without sending or persisting it.
Captured evidence
The workflow is visible at three decision moments.
These are direct captures from the local n8n demonstration on September 9, 2026. They show the design,
the human stop, and the weekly decision brief—not a production deployment.
01 · System viewAll five stages, exception paths, and the weekly operating rhythm in one zoom-to-fit frame.02 · Human controlThe synthetic path pauses at “Wait for Named Human Approval”; downstream action remains blocked.03 · Leadership outputThe manual weekly branch drafts priorities, capacity exceptions, pending approvals, SLA risks, and three recommended actions.
Open reqs9P0 2 · P1 4 · P2 3
Capacity exceptions2Engineering · Sales
Approvals waiting2Named decision owners
SLA milestones at risk3Recovery dates required
Designed to demonstrate control—not autonomous hiring.
The prototype keeps consequential authority with people and states plainly what would have to
change before production use.
What this demonstrates
A visible decision model from request through executive review.
Named approval, decision reason, accountable owner, and timestamp fields.
Exception paths for invalid intake, duplicate IDs, and declined decisions.
Capacity and SLA signals translated into specific leadership actions.
A repeatable weekly operating rhythm built from one governed data shape.
What this does not claim
No connection to live ATS, HRIS, Slack, email, candidate, or employer data.
No automated hiring, candidate-ranking, or employment decision.
No external notification, scheduled run, credential, or durable write.
No measured production outcome or claim that this is operating inside an employer.
No production-grade identity, access-control, audit-store, or data-retention layer.
From demonstration to production
The prototype proves the model. Production requires more controls.
Area
Synthetic demonstration
Production requirement
Data
Embedded fictional records
Authorized system-of-record data, minimization, retention, and lineage
Identity
Named approver field
Authenticated, signed, single-use approval with role-based access
Audit
In-memory decision fields
Durable, tamper-evident decision and exception log
Integration
No external sends or writes
Approved ATS/HRIS interfaces, error handling, retries, and reconciliation
Operations
Manual demo triggers
Monitoring, alert ownership, rollback, change control, and periodic review
My role and authorship.
I defined the operating problem, workflow stages, decision logic, control boundaries, and
acceptance criteria. I used AI-assisted development to accelerate implementation, while
retaining human accountability for consequential decisions.
The point is not that automation can replace recruiting judgment. The point is that a
recruiting leader can make judgment more consistent by designing where evidence appears,
who owns each decision, and what becomes visible when the system is under pressure.
What I would measure next.
Time from validated request to named capacity decision.
Share of priority changes with a recorded owner and rationale.
SLA risk identified before, rather than after, a missed milestone.
Exception age and recurring causes by function or approval owner.
Leadership actions closed between weekly operating reviews.
Want to see how I would adapt this to your operating model?
Building a recruiting function that needs clearer decisions, ownership, and operating rhythm?
I am open to remote Head of Talent Acquisition and talent operations roles with technology,
HR/workforce tech, and B2B SaaS companies, and to selected consulting engagements.
