Sample data you can trust · Self-initiated proposal for n8n · 2026

The test said Succeeded. The job it showed did not exist.

A self-initiated proposal for n8n's AI Assistant: when it tests a workflow without saving anything, show what would really happen, not a result it made up that looks exactly like a real one.

PRODUCT DESIGNAI UXINTERACTION DESIGNDESIGN SYSTEMSUX WRITINGMOTION

Today is a real, unedited capture from my n8n Cloud trial. Concept is my proposal, rebuilt in n8n's visual language. Not affiliated with n8n.

real jobs the test run read: 19
real job it kept, at OLX: 1
invented job shown as Succeeded: 1
separate approvals for one request: 3

Overview

n8n lets people automate work by connecting steps on a canvas, and its new AI Assistant builds those steps from a plain request. I tried it on a real task of mine: every weekday, find remote Product Designer jobs that hire from Spain and save them to a table. Before switching it on, the Assistant ran a test. So that the test would not save anything, it simulated the last step, and to do that it made up a result: a job at Travelperk, with a salary and a believable link. The run history said Succeeded, every step had a green check, and the real job the workflow had found, at OLX, sat one step earlier. Sample data you can trust is a feature I designed on my own and propose to n8n, so that a test run shows what would really happen instead of results that look real and are not. I took it from that real test to three directions, the screens for each and a component set ready to hand off. It is a concept, not affiliated with n8n.

Opportunities

Sample looks like sample
How might we make simulated output impossible to mistake for real output, wherever it shows up: canvas, output, history and chat?
Real data first
How might we show what a step would do with the real item, instead of inventing one?
Say what will happen
How might we tell people in plain words what changes when they run a step for real?
Ask once, keep the risky steps
How might we ask for permission once, without hiding the steps that write, delete or cost money?

Approach

01
What happened, in plain words
A test run is a rehearsal: the workflow runs, but steps that change things, like saving a row or sending an email, should not. n8n already lets developers pin data on a step so it returns the same result every time they test. The Assistant used that pin to fake the save step, and nothing on screen said so: only a purple border and a small pin icon, with no tooltip.
Real capture from my n8n Cloud trial, 3 Oct 2026.
02
Why it matters
When invented data looks like real data, trust breaks both ways: people act on a job, a customer or an invoice that does not exist, or they find out once and stop trusting every green check. Here the chat said the save step was simulated while the panel next to it showed Travelperk, and the Assistant only called the row made up when I asked.
The test run in the execution history: Succeeded, with the invented row. Real capture.
03
Five rules before drawing
Sample data looks like sample data everywhere. Show what would happen with the real data instead of inventing it. Say the effect in plain words. Give one clear way to make it real, with the consequence before the click. And fit n8n: extend what it already has, like the pin, the Kept and Discarded tabs on filters and the logs, instead of replacing it.
04
Direction A · Dry run preview
Nothing is invented. The save step runs dry and shows the row it would write, built from the real OLX job. Fields that only exist once a row is saved, like the id, say assigned on write. One button, Run this step for real, says what it will do before you click: write 1 row.
05
Direction B · Sample state
The smallest change. The simulation stays, but sample data looks like sample everywhere: the node is tinted with a Sample chip, the row is tagged, a banner names the real item from the step before, and the history says 1 step simulated. It grows out of the purple pin n8n already uses.
06
Direction C · Test run receipt
The biggest bet. A test becomes its own kind of run, with side effects off. A step that would write is Skipped, not Succeeded, and the run leaves a receipt of what ran and what was skipped. The canvas, the logs, the history and the chat all read from that one receipt, so they can never disagree.
07
Which one I would build first
Direction A. It is the only one that never shows invented data, and it reuses what n8n already has: the real item from the step before. B could ship sooner as a first fix. C is where I would take it next, once a single test can touch many tools at once.
08
One plan, approved once
For one request the Assistant asked three separate times: to read a URL, to create a table and to run the workflow. In the concept it shows its plan first and you approve it once. Anything that writes for real, deletes data or costs money still asks, one by one.
09
Examples that follow the request
Before I had asked for anything, the Assistant suggested security automations, like 1Password exports and Entra ID alerts. In the concept the examples follow what you are typing, so a job search brings job search examples.
10
Built to hand off
One node with six named states: three that exist today and one new state per direction. Every color is a variable, and the banner all three share is annotated with spacing and type, in a file organized one page per direction: 12 components, 44 color variables and 18 text styles.

Impact & Outcomes

Three directions, each shown in the same three moments: the editor after a test run, the Assistant chat and the execution history.
A component set ready to hand off: one node with six named states, color variables and annotated specs.
What I would test next: whether people can tell a test from a real run without reading, how often they run a step for real after a preview, and whether the receipt in C is worth its extra weight.