A solo run is a way to run a single step on its own, without setting off everything that comes after it. It's one of the most useful tools while you're building, because it lets you test one piece of a workflow in isolation and see exactly what it does.
Just this step, nothing downstream
When you solo run a step, Tines 3B executes that step and stops there. The steps connected after it stay put, even though they'd normally fire once this step produced output. You get the result of the one step you care about, and nothing else in the workflow moves.
That's the whole idea captured in the name: the step runs solo. It's the counterpart to a full run, where a step's output flows on to the next steps and the workflow carries on through to the end.
Why you'd use one
Solo runs are built for the back-and-forth of building. When you're working on a step, you usually want to know one thing: does this step do what I expect? A solo run answers that immediately, without waiting for the rest of the workflow to run and without triggering actions further down that you're not ready to set off. You can tweak the step, solo run it again, and keep iterating until it's right, all while the steps around it stay untouched.
That makes solo runs especially handy for steps that would otherwise have real consequences downstream, like sending a message or updating a record. You can confirm the step in front of you works before you ever let its output reach the next step.
Solo run vs. run
Both actions start from the same place, and it helps to see them side by side:
Solo run. Runs only the selected step. Downstream steps don't fire.
Run. Runs the selected step and lets its output flow into the steps that follow.
When a step has nothing after it, there's no difference to make, so you simply get a solo run. When it does have downstream steps, you choose between running just this one or running the whole chain from here.
It stays out of your run history
A solo run is meant to be quick and disposable, so it's treated as a throwaway rather than a real run of the workflow. It doesn't appear in the workflow's run history and doesn't cascade to other steps. This keeps your history focused on the workflow's actual runs, the ones triggered on a schedule or by a request, rather than filling it with every experiment you did while building.
The result of a solo run still shows up on the step itself, so you can inspect its output and logs right where you're working.
Where to trigger one
You start a solo run right from the step you're building, using the step's run controls or its menu.
When a step has downstream steps, the run control splits in two: one side for a solo run, the other for running everything from that step onward. Tines 3B's assistant can solo run a step for you as well when it's helping you build, so the same quick, isolated execution is available whether you trigger it yourself or ask for it.