When Visual Isn't Enough: The Code Step

Visual workflow builders are great. You drag blocks around, connect them, configure inputs, and ship an automation without writing a line of code. That is the whole point of QuickFlo, and it works really well for the vast majority of what people need to build.

But “vast majority” is not “everything.”

The limits of visual-only

Every visual workflow tool hits a wall eventually. You need to parse a CSV that has some non-standard quoting. You need a scoring algorithm that weights six different fields with custom thresholds. You need to call an API that requires HMAC-signed headers. You need to transform a nested JSON response into a flat table, but the nesting is inconsistent and the keys change depending on the record type.

These are not exotic requirements. They come up constantly in real integrations. And in most workflow platforms, this is where you start fighting the tool — chaining together five steps to do what three lines of code would handle, or giving up and moving the logic outside the workflow entirely.

We did not want QuickFlo to have that wall.

Introducing the Code step

The Code step lets you write TypeScript or JavaScript that runs as a first-class step in your workflow. It is not a workaround or a plugin. It is a step, the same as any other. It receives input from previous steps via the workflow context, executes your code, and its return value becomes the step output that downstream steps can reference.

// Access data from a previous step
const records = inputs.fetchRecords.data;

// Do whatever you need
const scored = records.map(record => ({
  ...record,
  score: calculateScore(record.revenue, record.engagement, record.recency),
  tier: record.revenue > 50000 ? 'enterprise' : 'standard',
}));

return { scored, totalProcessed: scored.length };

Other steps reference the output like any other step in the workflow: {{ codeStep.scored }} or {{ codeStep.totalProcessed }}. No special wiring, no adapters.

Why Deno

Running arbitrary user code inside a workflow engine is a serious design decision. We chose Deno as the runtime for a few specific reasons.

Secure by default. Deno runs with no permissions unless you explicitly grant them. Network access, file system access, environment variables — all locked down by default. This matters when you are running code inside a shared execution environment.

TypeScript native. No build step, no tsconfig wrangling. Write TypeScript and it just runs. For a workflow step where you want to write a quick transformation, eliminating build complexity is the right tradeoff.

Fast cold starts. Workflow steps need to spin up quickly. Deno’s architecture is built for this — no heavy Node.js bootstrap, no module resolution overhead for simple scripts.

Modern standard library. Deno ships with a solid standard library and supports importing from URLs. Need a date library or a CSV parser? Import it directly without managing a package.json.

What people are building with it

The Code step is already in use across production workflows. Here is where it shows up most:

• Custom data transformations — reshaping API responses, flattening nested structures, merging datasets with custom join logic that does not fit into the built-in data steps.
• Business logic — lead scoring algorithms, matching and deduplication rules, conditional routing that depends on calculations rather than simple field comparisons.
• Unusual API integrations — APIs that require signed requests, custom token exchange flows, or non-standard request formats that the HTTP step cannot express directly.
• String and date work — parsing free-text fields, normalizing phone numbers, calculating business days between dates, formatting data for downstream systems that expect specific layouts.

It is an escape hatch, not a replacement

This is an important distinction. The Code step exists for the cases where visual steps are not the right tool. It does not replace them.

Visual steps are better for the straightforward 90%. They are readable, configurable without opening an editor, and they make the workflow’s intent obvious at a glance. When you can use a visual step, you should.

The Code step is for the other 10% — the custom logic, the edge cases, the transformations that would be painful to express visually. It means you never have to leave QuickFlo to handle those cases. Your entire workflow lives in one place, executes as one unit, and is observable through the same execution trace.

Try it out

The Code step is available now in all QuickFlo workflows. Drop one into your next workflow and see how it fits. If you have been working around visual step limitations with external scripts or complex step chains, this is probably what you have been waiting for.

Check out the Code step documentation to get started, or book a call if you want to talk through a use case.