Return Result Block: The Key to Clear & Structured Output

One of the most common pain points in building automations is the “mystery output.”

You run a flow, check your logs, and get a wall of unstructured data. Some values are buried in nested objects. Others don’t have meaningful labels. And when you try to hand that workflow off to a teammate, they’re left asking:

“What exactly am I looking at here?”

So we introduced Return Result; a feature designed to solve that exact problem.

What Is Return Result?

Return Result isn’t a new block you drag into your flow. Instead, it’s a better way to define and structure the outputs your flows generate.

Think of it as a layer between your workflow logic and the outside world. Instead of passing along raw, unorganized data, you can:

• Name fields clearly so your results make sense at a glance
• Group related values together into a structured result object
• Control what appears in TestMonitor for cleaner debugging
  

The result? Flows that are easier to understand, share, and scale.

Why It Matters

When you’re building automation for yourself, you might be okay with messy outputs. But the second you:

• Hand it off to a teammate
• Use it as part of a client deliverable
• Or connect it to downstream systems

…those unstructured results become a liability.

Messy outputs lead to:

• Confusion (“Which field is the actual email?”)
• Errors in downstream automations
• Hours wasted debugging

Return Result turns leaves you with a perfectly formated output.

How It Works

Here’s what you can do with Return Result:

1. Define Outputs Explicitly
   Decide what you want your flow to return, and name it. Instead of result_43f29a, you now have CustomerEmail.
2. Organize for Readability
   Group values logically — e.g., CustomerInfo with fields for name, email, and plan type.
3. Debug Faster in TestMonitor
   Instead of scrolling through massive JSON blobs, your outputs show up cleanly formatted and easy to interpret.
4. Make Downstream Workflows Easier
   Any flow or system consuming your results will thank you. Structured outputs mean fewer mistakes and simpler integrations.
   

Real Example

Let’s say you have a workflow that:

• Pulls new leads from HubSpot
• Enriches them with Clearbit
• Scores them based on company size

Before Return Result, your TestMonitor output might look something like this:

{
"hubspot_123": { "email": "jane@example.com", "id": 932843 },  
"clearbit": { "company": { "size": 201 } },
"score": 4
}

Useful, but messy.‍

With Return Result, you can reframe the output as:

{
"LeadEmail": "jane@example.com",
"LeadID": 932843,
"CompanySize": 201,
"LeadScore": 4
}

Much easier to read, debug, and hand off to downstream automations.

The Bigger Picture

Return Result is part of Flowrunner’s broader mission:
to make building automation feel less like hacking and more like engineering.

Just like software developers learned long ago that structured outputs and clean interfaces matter, automation builders now have the same power.

Instead of fragile, ad hoc workflows, you’re creating reliable systems with clarity baked in.

Try It Out

If you haven’t yet, open a flow in Flowrunner, run it in TestMonitor, and look for the Return Result option. Start defining your outputs clearly; your teammates, clients, and future self will thank you.