Using Storyblok’s FlowMotion: 10 lessons to learn early

The upcoming launch of FlowMotion is about to transform the way developers and content teams work with Storyblok. If you're just getting started with workflow automation, a few habits can save you hours of debugging and iterations.

This article includes 10 tips and best practices that Storyblok's developers learned the hard way, so you won't have to.

1. Test with a manual trigger

Your goal is to trigger a workflow with an actual action, like a Storyblok webhook node. But going back and forth while building a workflow can be a real pain.

Consider developing a workflow with this alternative approach:

1. Create a webhook trigger that targets your desired action and the rules you want to apply.
2. Update your target content to trigger the webhook.
3. Copy and paste the response as mock data within a manual trigger node.

This makes development smoother and faster, as you can run the workflow on demand without waiting for the “real” event to occur. This way, you focus on building and debugging core functionality rather than dealing with potential headaches caused by external actions.

2. Run one node at a time when testing and building

Instead of running an entire workflow to test it, execute one node at a time. This helps track where the data shape changes, making debugging much easier. If you run the whole chain at once, a failure on node X might actually be caused by bad output from node Y. Stepping through them one at a time makes the source obvious.

3. Don't default to the code node

Code nodes are powerful, but they add maintenance cost and make workflows harder to scan. Before writing code in a code node, search for one that already does the thing you need.

Use this quick cheat sheet:

• Handle conditionals: if or switch nodes
• Map and shape data: edit fields or set nodes
• Combine items: merge, aggregate, or summarize nodes
• Add or remove items: filter, limit, remove duplicates, or split out nodes

Save the code node for when you truly need custom logic, or when an expression-based solution would be messy and brittle.

4. Normalize early with edit fields

If you normalize your data early, everything downstream gets simpler. Otherwise, you'd end up referencing deeply nested fields like body.data.stories[0].content.title in multiple nodes, and when the API response shape changes, all six break.

Practical habit: right after an API call or webhook, map the payload into a clean object you control. This is also the best time to rename fields to match the language of your workflow.

5. Use the “Send and Wait for Response” node for human steps

This is the cleanest pattern for approvals and handoffs that require a person to confirm changes before publishing. No need for custom code or complex node grouping to achieve this.

Here are a few examples of these steps:

• Approve a translation before publishing
• Confirm a content change
• Provide missing information

6. Wield the power of n8n expressions

FlowMotion is built on n8n and uses its built-in methods and variables for working with data.

Under the hood, n8n expressions also support JMESPath for querying and reshaping JSON.

For example, say you have a response object from Storyblok that includes a list of stories, and you need the IDs of those published within the last 30 days. Combining built-in methods and JMESPath, you can do this inline with:

{{ 
  $jmespath(
    $json,
    "stories[?published_at >= `" + $now.minus({ days: 30 }).toISO() + "`].id"
  )
}}

You can also reference previous node outputs within an execution.

For example, if you need the ID of a story that was included in the initial input data that triggered your workflow, reference that node’s output. It should look something like:

{{ $('Workflow Trigger').item.json.story_id }}

This minimizes the risk of bugs when the workflow changes, since you reference a specific node’s output rather than the current node’s input. This makes your workflow more resilient, because references won’t break when nodes are added, removed, or reordered.

7. Use the execution data node as short-term memory

Execution data is useful for values you compute once and then reuse multiple times within the same run.

For example, if you check whether an asset already exists, store the result once. The following nodes can reference it, avoiding duplicate calls and logic. Think of it as a variable scoped to a single execution.

8. Store state in a data table

Use a data table when your workflow needs to access some data between executions.

Common use cases:

• Persisting data across workflows in the same project
• Storing markers to prevent duplicate runs or control workflow triggers
• Reusing prompts or messages across workflows
• Storing evaluation data for AI workflows
• Storing data generated from workflow executions
• Combining data from different sources to enrich your datasets
• Creating lookup tables as quick reference points within workflows

The rule is straightforward: If the workflow needs memory after the run finishes, it belongs in a table.

9. Debug with past executions

Past executions that include real input and output are one of the fastest ways to debug. You can reuse data from a previous run in your current workflow.

This is especially helpful when debugging failed production runs: open the failed execution, adjust your workflow, and rerun it using the same execution’s input data. No need to recreate the conditions manually.

10. Use sticky notes to document intent

Sticky notes make workflows self-documented. Without them, the future you and your teammates will have to open every single node and review the configuration to understand what's happening.

What to document:

• Why a branch exists
• Assumptions about the incoming data shape
• Reminders about rate limits, retries, or manual steps

To make maintenance and debugging even easier, ensure others can understand the workflow steps and purposes right from the canvas view.

Takeaways

Building workflows can be joyful if you follow these tips:

1. Start with manual triggers, so you're not fighting external events while you build.
2. Normalize your data early so that every downstream node works with clean, predictable input.
3. When something breaks in production, lean on past executions to replay the exact failure instead of guessing.

Those three habits alone will speed up and improve your FlowMotion automations.

Explore n8n's documentation to learn more best practices.

Have a workflow tip we missed? Share it in our Discord, and it might end up in the next list.