The JavaScript step: writing small scripts for bigger flow logic
Use the JavaScript step, in Logic & data, when a calculation or conditional check is too fiddly for Condition and Set Variable alone — write code that reads input variables, Test run it with sample values, then pick which returned fields become flow variables. Keep it for pure logic; use HTTP request or Google Sheets blocks for anything reaching outside the flow.
- Reach for JavaScript when a calculation or format needs more than Condition and Set Variable can express simply.
- Test run with sample values before wiring the block into a live flow.
- Only the output fields you explicitly pick become usable flow variables afterwards.
- Keep the JavaScript step for computation, not for reaching outside the flow — use HTTP request or Google Sheets for that.
- A script error shows in the test panel immediately, so fix it there before publishing.
When to reach for the JavaScript step
Most flows never need it. Condition, Set Variable and the built-in blocks cover routing and simple logic. Reach for JavaScript (in the Logic & data category) when you need something those blocks can't express cleanly: a calculation across two or three variables, reformatting a date or currency value for display, or parsing a nested field out of a JSON response an earlier HTTP request step returned.
A rough rule of thumb: if you find yourself chaining more than two or three Condition steps just to express one piece of logic, that is usually a sign a short script would be clearer and easier to maintain than the equivalent tangle of branches.
Inputs, outputs and the exact click path
- Add a JavaScript block from the Logic & data category.
- Reference the flow's existing variables as inputs inside your script.
- Write code that returns an object: each key becomes a candidate output field.
- Use Test run with sample values to check the result before going further.
- Pick which returned fields to save as flow variables for later steps to use.
Name the output fields descriptively, formatted_amount reads far better six months later than a generic result or output1 when someone else is trying to understand what a downstream step depends on.
Worked example: formatting an order total for a message
A flow has captured an order amount as a plain number (4500) and wants it displayed nicely inside a WhatsApp message as '₹4,500'. A short JavaScript step takes the amount variable as input, formats it with a thousands separator and the ₹ symbol, and returns an object like formatted_amount. After a test run confirms it reads correctly, that single output field is picked and used in a Send Message step further down the flow, something that would be awkward to express with Set Variable alone.
Keeping it to logic, not network calls
The JavaScript step is for computation on data already inside the flow, not for reaching outside it. That's what the dedicated HTTP request and Google Sheets blocks are for. Splitting responsibilities this way keeps a flow easier to read and debug: anyone looking at it can tell at a glance which step talks to the outside world and which step is just doing maths or formatting.
It also makes a flow easier to hand over, a teammate reviewing it later does not need to trace through a script wondering whether it silently calls an external service somewhere inside. This separation also matters for reliability: a network call can time out or fail for reasons entirely outside your control, while a pure calculation on values already in the flow either works or shows its error immediately in the test panel, with no external dependency to go wrong later.
A second worked example: a simple discount calculation
A flow captures an order amount and a discount percentage as two separate variables from earlier steps. A JavaScript block takes both as input, calculates the discounted total, and returns an object with the result. Rather than trying to express a percentage calculation through nested Condition and Set Variable steps, one short script does it in a single step, tested once with a few sample amounts before being trusted in the live flow.
Troubleshooting
| Symptom | Likely fix |
|---|---|
| Test run shows a script error | Check the error message in the test panel, usually a syntax issue or a variable name that doesn't exist yet. |
| Output variable not available in a later step | You need to explicitly pick which returned field to save as a variable. It isn't automatic just because the script returned it. |
| Numbers behave like text | An input variable captured from a customer's typed answer often arrives as text. Convert it explicitly inside the script before doing maths on it. |
| Script feels slow or seems to hang | Check for an accidental infinite loop in your own code, the most common cause. |
| Trying to call an external API from inside the script | Use the HTTP request block instead. The JavaScript step is for logic on data already in the flow. |
What to test before going live, and cost
- Test run with several different sample values, including edge cases like zero, a negative number, or an empty string.
- Confirm every output field you actually use downstream was explicitly picked as a saved variable.
- Check the step's behaviour when an expected input variable is missing, since a real customer's flow path might skip a step you assumed would run first.
There's no extra Convo360 charge for using the JavaScript step. It's part of the flow builder available on every plan, with the usual AI token or messaging costs applying only to the other steps in the same flow.
Treat the few minutes spent testing edge cases as cheap insurance against a script that quietly breaks a live flow for one unlucky customer weeks later. A script that has never seen a blank input or an unexpected type is a script waiting to fail on exactly the customer you least expect it to, and that small habit of testing edge cases up front tends to save far more time than it costs.
Step by step
- Add a JavaScript blockDrop it into your flow from the Logic & data category.
- Reference input variablesUse the flow's existing variables as inputs inside your script.
- Write code that returns an objectEach key in the returned object becomes a candidate output field.
- Test run with sample valuesCheck the result in the test panel before relying on it in a live flow.
- Pick output fields to saveChoose which returned fields become flow variables for later steps.
Example conversation
Explore the flow builder
Start free in minutes — no code, no credit card. Bring your own AI keys and pay no per-message markup.
Frequently asked questions
When should I use the JavaScript step instead of Condition and Set Variable?
When the logic is too fiddly for those blocks alone — a calculation across several variables, date or currency formatting, or parsing a nested field from an API response.
Can the JavaScript step make its own API calls?
It's meant for logic on data already in the flow, not for reaching outside it — use the dedicated HTTP request or Google Sheets blocks for external calls.
Why doesn't my script's output show up in a later step?
You need to explicitly pick which returned field to save as a flow variable — it isn't saved automatically just because the script returned it.
How do I check my script works before publishing?
Use Test run with sample values, including edge cases like zero, a negative number or an empty string, and check the result in the test panel before wiring the block into a live flow. A script error shows up immediately there, so you can fix it before a real customer ever hits it.
Does the JavaScript step cost extra?
No, it's part of the flow builder on every plan, with no separate charge beyond your usual AI token or messaging costs for the other steps in the same flow. Writing and testing scripts inside the builder itself has no metered cost at all, however many times you run Test run.
Related reading
Available across India — see WhatsApp & AI calling automation by state and city.