Built work
An n8n foundation
A proof of concept covering intake, mapping, validation and logging. It establishes the core workflow rather than a live publishing service.
Bastion / Workflow automation
From asset submission to confirmed delivery.
I built an n8n workflow for Bastion, then developed the design around the checks and exceptions that reliable asset delivery needs. The interactive demonstration shows how a request moves through validation, suitable repairs, human review and delivery confirmation.
Explore the work
- The challenge
- Move advertising assets to the right destination with the right details, permissions and confirmation.
- My contribution
- Workflow logic, intake and validation, exception handling and system design.
- The evidence
- A built n8n foundation and a later interactive design. External services and delivery are simulated.
01 / The challenge
A ready file needs
a reliable handoff.
Moving an advertising file is only one part of delivery. The request needs the correct destination and usage permission. The asset must meet placement rules. If a service fails or a response is uncertain, someone needs to know what happened and what to do next.
I approached the problem as a complete request lifecycle, including corrections and recovery. A failed check should lead to a useful next action; a send should be recorded as complete only when delivery is confirmed.
Make the next action clear, especially when the request cannot proceed.
02 / What I did
Define the checks.
Design the recovery.
Built the workflow foundation
Created an n8n proof of concept for request intake, placement mapping, validation and logging. It established the sequence and information needed to handle a request.
Made exceptions part of the design
Extended the design to cover missing details, permissions, unsuitable files, service failures and uncertain delivery responses. Each unresolved condition leads to a correction or a named human decision.
Set limits on automated actions
Specified that repairs preserve originals, changes are checked again, retries have a limit, and an uncertain send is checked before another attempt. These controls make recovery inspectable.
Built an interactive walkthrough
Turned the system design into 21 scenarios. A visitor can follow the same request through the workflow map and the delivery screen, inspect each decision and see why the next step changes.
03 / Explore the workflow
Follow a request
through the system.
Start with a successful delivery, then try a missing field, a file correction or a service failure. The separate demonstration includes the full map, step-by-step explanations and recovery paths.
04 / Results
A working foundation.
A fuller system design.
Design coverage
21 scenarios
The later 17-node system design covers successful delivery, file repairs, corrections, retries and requests that need human attention.
Reviewable work
Visible decisions
The interactive walkthrough makes the request state, check result and next action visible at each step.
The demonstration extends the original workflow to show a proposed production design. External services, file changes and delivery receipts are simulated. The case demonstrates workflow design and operational judgment; it does not claim that the complete system published live advertising assets.
A related challenge?
Start with the problem.
Make the next step useful.
For conversations about measurement, applied AI and digital experiences that help people act.
Start a conversation