You notice it the second time you do a job with the same steps. Looking at the same places every Monday and pulling the same summary, filling the same three fields every time a request comes in, collecting the same report every month. The work itself is not hard. The repetition is tiring.
In Orbi these jobs become flows. A flow is work that runs on its own when a trigger fires. It does not appear on the board as a card. It lives in its own tab and records what it did every time it runs.
What starts a flow
There are four kinds of trigger, and the kind you choose sets the character of the work.
A recurring trigger runs at set intervals. Every morning, every Monday, the first of the month.
A one-off reminder runs once and is done. For work that has to happen on a specific date.
An event trigger kicks in when something happens inside Orbi. A record landing in a collection, a card changing state or a card being assigned to someone.
A service trigger runs when something happens in an external service you have connected. An incoming email, a comment on an issue or a pull request being opened can start the work.
A flow can have more than one trigger. Whichever fires, the same work runs, so you can have a report run automatically every morning and also trigger it by hand when needed.
The canvas reads as one sentence
Click a flow and the canvas opens. The canvas shows what starts the flow and then who does what.
The trigger cards sit at the top. Below them the Start node they all connect to, and below that the agent cards that do the work. You drag agents in from the list on the left. Drop an agent onto another agent and it slots in to run after it.
If the cards pile on top of each other, one button lays them all out cleanly. It looks like a small thing, and on flows past six cards it is what keeps the canvas readable.
The simplest flow is a single trigger and the Start node. In that case Orbi's own assistant does the work.
There are no data-transformation or connection-request cards on the canvas. That is a deliberate simplification, because the expertise lives in the agent's instruction. The canvas only shows who runs after whom, and under what condition.
Put the goal in the middle and each share on its card
You can write text in two separate places, and they do different jobs.
The job description on the Start node belongs to the whole flow and every agent reads it. Put the flow's goal there.
Each agent card's own instruction applies only on that card. Put that agent's share there.
Skipping this distinction gets expensive. If you list four jobs step by step in the job description, every card reads all four and everyone tries to do everything. Writing the same text both in the job description and on the card hurts too, because the card ends up reading it twice.
If you have attached an agent to Start, you can leave the job description empty. The card instructions describe the work.
Write the condition in your own words
Not every parallel branch has to fire on every run. You hover over a connection, add a condition and write your own sentence. "If the customer is complaining", for instance.
A conditional connection is drawn dashed with your sentence on it. When the previous step finishes, Orbi judges its result against that sentence. If the sentence does not hold, that branch does not run.
The condition being a sentence rather than a form is also deliberate. Agent results are text, and a rule shaped like "field equals value" cannot express most of them.
If several paths lead into one step, the step runs when at least one of them passes. "If X" and "if not X" do not complement each other, because the condition is put to the previous step's result, not to the world. When no decision can be reached the branch does not run, because running the wrong branch in an uncertain situation can send a message out.
No branch is skipped silently. The run history shows separately that the condition held, that it did not, and that no decision could be made.
The agent does not invent missing information
An agent writes only values that are actually present in its input or in a tool's result. If there is no phone number in the incoming message, that field stays empty. No plausible-looking number gets made up.
Missing information is listed in the output, and you fill it in if needed. An empty field tells you nothing, but a made-up field tells you something false and you believe it.
Try it before it sends anything
The Test button really runs the flow. The model runs, the reading tools run against real data. None of the tools that write outward run.
So instead of opening a task, writing a record or sending a message, a "this is what I would have done" preview lands. The run summary lists those actions one by one, and the cards on the canvas still turn green or red. When you test an event trigger, the rehearsal uses the data from the last event that actually happened.
Do not skip this step when setting up a flow for the first time. A wrongly built flow sending a message out on its first real run is the hardest mistake to fix.
You can read what happened afterwards
Every run leaves a record. The Runs tab shows the status, the time, how many steps it took and what it started from. If an incoming message triggered it, the sender and the subject sit there.
That record is the only way to trust a flow. When an output does not come out as expected, you look at what each step produced and make the fix in the right place.
Pausing is an option too
You can stop a flow without deleting it. A paused flow does not respond to its triggers but its definition stays in place, and when you resume it, it carries on from where it was. It is the way to park a flow you set up to try something without deleting it.
You can also duplicate a working flow. When setting up the same arrangement for a second client or a second channel, you do not start from scratch.
Where to start
Pick a job you already do. Do not invent a new one, because you only see the value of a flow when you compare it with a job you did by hand.
Build the first flow with one agent and no conditions. Run it a few times with the Test button, read the output, fix the instruction. Add conditional branches only once the basic flow has settled.
A scheduled job does not remember the output of its previous run on its own. If you want continuity, have the job write its output to a collection and have the next run read that collection and carry on.
Trigger types, condition behaviour and run history are covered in detail in Flows and calendar in the help center.
If you want to try it, you can open a free account and build your first flow.