Your first flow

Ten minutes. You will build a flow that asks a web service for your public IP address and shows it in a dialog box. It is deliberately small, because the point is not the result — it is to see what a flow, a node and a robot each are.

You will do it twice

The Flow Designer opens on a prompt box — "Build a flow that…" — and the AI Assistant will produce this flow from one sentence. That is usually the right way to start real work, so this tutorial does both, in this order:

1. By hand, node by node — most of this page.
2. By prompt, at the end, in about thirty seconds.

Doing the slow one first is the point. The Assistant gives you a draft, and a draft is only worth having if you can read it. Its mistakes are rarely loud: a selector that works today and breaks at the site's next deploy, a branch that quietly fires on no port at all, a missing error path. Recognising those needs the model in your head — and building five nodes by hand is the cheapest way to get it.

After this page, use the Assistant for everything. You will just be able to review what it hands you.

What you need

• A workspace (create one)
• A connected robot (connect one)

The flow you are building

Five nodes, left to right. Read it as a sentence: start, decide which address to call, call it, show the answer, stop.

You will build it one node at a time, so each addition has a reason before it appears.

The four things on that canvas

Before building it, it is worth naming what you are looking at, because these four words appear on every page of these docs.

A node is one step. It does a single thing — send a request, read a file, click a button. The label above the name (Net → HttpRequest) tells you which package it comes from and which node it is.

A port is the small dot on a node's edge. Execution enters the left port and leaves the right one. Connecting one node's output to the next node's input is how you say "then do this".

A flow is the whole canvas: nodes plus the connections between them.

A robot is what actually runs it. The flow is a design; the robot is the worker. Nothing happens until a robot picks the flow up — which is why you needed to connect one.

Build it

Create a new project in the Flow Designer and name it First Flow. Then add the nodes one at a time — right-click empty canvas to search by name, or drag from the palette on the left.

Build it in this order and watch the sentence assemble.

1. Something has to start it

Add an Inject node (Trigger → Inject) and rename it Start.

Every flow needs a way in. Inject is the simplest: it fires once and creates the message that travels through everything else. Later you will swap it for a schedule or a trigger, but the shape of the flow does not change.

Why rename nodes

The default names describe the mechanism; a good name describes the intent. On a flow with forty nodes, Show IP Address saves you opening a node to remember what it was for. Every template in the library is named this way.

2. Decide what to call

Add a Function node (Programming → Function), rename it Config, and connect Start to it by dragging from the right-hand port to its left-hand port.

Open its menu, choose Edit, and paste:

msg.service_address = "https://ifconfig.me";
return msg;

That writes a field onto the message. Nothing calls it yet — you have just put the address somewhere the next node can read it.

Why not type the URL into the request node

You could. Doing it here means the address is defined in one obvious place instead of buried in a node's properties, which matters the moment two nodes need it or it has to change per environment.

3. Make the call

Add an HTTP Request node (Net → HttpRequest), rename it Send Request, and connect it.

Set its properties:

Property	Value
Method	GET
URL	Message → service_address

Note what you just did. Instead of typing the URL, you pointed the node at a value the previous node put on the message. That is the single most important idea in the product, and tutorial 2 is entirely about it.

4. Show the answer, and stop

Add a Message Box (Dialog → MessageBox) renamed Show IP Address, then a Stop (Flow → Stop). Connect both.

Set the Message Box's properties:

Property	Value
Title	Custom → Your IP Address
Text	Message → resp

Save with the toolbar's save icon, or Ctrl-S.

Saving is committing

Each save commits the flow to its own git history, so you can compare any two points later with Visual Diff. Nothing to set up — it is already happening.

Run it

Click the play icon and choose Desktop, then pick your robot and press RUN.

If Desktop is greyed out, no robot is connected — see Connect Robot.

A dialog appears with your public IP address in it. Your robot just made an HTTP request on your behalf and reported back.

What actually happened

The Inject node fired once and created a message. That message travelled left to right along the connections, and each node was free to read it and add to it:

1. Start created an empty message.
2. Config added a service_address field to it.
3. Send Request read service_address, called it, and added the reply as resp.
4. Show IP Address read resp and displayed it.
5. Stop ended the run.

Nothing was passed between nodes except that one object. That is the whole execution model — and it is the subject of the next tutorial.

Try changing it

• Point msg.service_address at https://api.github.com/zen and run it again. The flow does not care what it is calling.
• Add a Debug node (Flow → Debug) after Send Request and run again. The Debug panel shows the entire message at that point, which is how you inspect a flow that is not doing what you expect.

Now do it the fast way

Open a new project and, in the prompt box on the Designer home page, type something like:

Ask a web service for my public IP address and show it in a message box.

Press Build. The AI Assistant produces a flow.

This needs an agent, not a robot

If the page says No Connected Agents, the Assistant has nothing to work through. That is a different program from the robot you connected earlier — see robomotion-agent:

robomotion-agent connect -i your_email -w your_workspace

Then read what it gave you

This is the part that matters, and it is why you did the previous section.

• Which nodes did it choose? An HTTP Request and a Message Box, most likely — the same ones you picked. If it reached for a Browser node instead, it has misunderstood the task.
• Where does the URL come from? A Config-style Function node, a literal typed into the node, or a variable? All three work; only one is easy to change later.
• Which field does the Message Box read? If it guessed a field name the request node does not actually write, the flow runs and shows nothing. Add a Debug node and check.
• What happens if the request fails? Usually: nothing. There is no Catch and no Continue On Error, so the run just stops. Tutorial 5 is about fixing that.

None of those questions are answerable without the model you built in the first half of this page. That is the whole argument for doing it by hand once.

Next

Passing data between nodes → — the message object in detail, and the Config-node pattern you just used without explanation.