Buttons gives you four different ways to make something happen: a direct action on a button, a routing Preset, a Cuelist, or a workflow. All four can "do things" once triggered, so it's easy to reach for the wrong one: building a workflow for something a single button already handles, or wiring up individual buttons where a Cuelist would keep a long list organized. This page helps you decide which one fits a task before you build it, so the result stays as simple as the job actually requires.
Each mechanism has its own guide with full instructions: this page compares them; it doesn't replace them.
Before you begin#
This assumes you're already familiar with the basic building blocks (connections, positions, and buttons) from
What is Bitfocus Buttons?. You don't need to have built a routing Preset, Cuelist, or workflow yet.
How they fit together#
Three of these aren't really alternatives to pressing a button: they're what a button (or a schedule, or an incoming event) can invoke. The real decision is usually about where a task's order, state, and logic should live, not whether a person presses something:
- A button's own action stack can already run several actions together or in sequence, and can branch on a condition: the same building blocks a Cuelist's cues use internally. Reach for it directly whenever one control performing its own actions is enough.
- A routing Preset is a saved list of source-to-destination mappings, not a sequence or a program. Use it when the task is "put these signal routes back to a known configuration," whether that configuration was built by hand or captured from routes that were already live.
- A Cuelist is a standalone, ordered list of cues that keeps its own "what's next" position, independent of any position or button. Use it when steps genuinely need to happen in a determined order, or when a long list of similar actions is easier to manage as scannable rows than as many separate buttons.
- A workflow is the only one of the four that can start from something other than a press (a schedule, a timer, an NFC read, an incoming HTTP/OSC/TCP/UDP/WebSocket request, or a connection's own state changing) and the only one that keeps its own retained values (workflow variables) available everywhere. Use it when the task needs that kind of trigger, needs to compare or transform values over time, or needs to talk to another system. A workflow can also call a routing Preset or advance a Cuelist itself, so it can sit above the other three instead of duplicating what they already do.
Note
None of the four requires a specific paid license tier by itself. An unlicensed Free installation does cap how large a single Cuelist or workflow can grow (32 cues in total and 32 nodes per workflow), but places no equivalent limit on a routing Preset or a button's own action stack.
Compare what each one needs#
| Button action stack | Routing Preset | Cuelist | Workflow |
|---|
Typical trigger | Press (or release, left, right, encoder) on that control | A button, a Custom Router control, or a workflow | The Cuelist Command action, from any button, position, or workflow | A schedule, timer, NFC read, incoming request, connection state change, or a button press |
Runs in a set order | Only within its own action stack (grouped or conditional steps) | No: it's a set of mappings, not a sequence | Yes: that's its purpose, including nested sub-cues | Follows the graph you build, not a fixed row order |
Keeps its own state | No dedicated state beyond its own feedback-driven styling | No: a static list until re-saved or replaced | Yes: which cue is next or running | Yes: workflow variables persist and are readable everywhere |
Reusable across positions | Only via a Shared Section | Yes: a standalone resource, callable by any Custom Router or button | Yes: a standalone resource, controllable from any position | Yes: a standalone resource; can also drive the other three |
Needs a license tier | No | No | No (Free tier caps total cues at 32) | No (Free tier caps nodes at 32 per workflow) |
Typically built by | Anyone setting up a control | An integrator with routing access | Anyone organizing a show order or a long list of actions | An integrator or engineer building custom logic |
Examples#
Recall a known-good routing layout for a returning show#
A broadcast engineer preps a control room ATEM every Wednesday morning for a weekly panel show that always uses the same four inputs on the same M/Es. Once the routes are confirmed correct for that week, they capture the currently active routes into a routing Preset labeled Wednesday panel show. The next time the show returns, one press of a Direct Take Preset control on the Custom Router restores every route at once, instead of re-selecting four sources and destinations by hand.
- Best fit: routing Preset. The task is entirely "put these routes back," with no ordering between them and nothing that needs to happen automatically over time.
- Close second: a button with several stacked "Take Route" actions. This works for a small, fixed number of routes placed directly on one control, but it can't be captured from live routes the way a Preset can, and it isn't a named, standalone resource other panels can reuse: every additional panel needs its own copy of the same action stack.
Run a determined VTR and graphics rundown for a live segment#
A studio runs a short segment built from three pre-produced clips and two graphics inserts that must play in the same order every time, with a director calling each move. The team builds a Cuelist with one cue per clip or insert, each firing the connection actions needed to start playback or bring in the graphic, and groups the two graphics cues as sub-cues under the segment's parent cue. During the show, the director's position holds Select next/Select previous controls and the technical director's position holds Execute selected (GO), both pointed at the same Cuelist.
- Best fit: Cuelist. The steps must happen in a specific, known order, more than one person needs visibility into what's next, and the list is long enough that scanning rows beats hunting across a canvas full of individual buttons.
- Close second: several individual buttons, one per step. This works when there are only two or three steps and one person runs all of them, but it puts the burden of remembering the correct order on the operator instead of the system, and it doesn't give a shared "what's next" indicator the way a Cuelist does.
An unattended webcast should switch its program feed from a wide establishing shot to a presenter close-up at the same time every day, with nobody available to press a control at that exact moment. A workflow uses a Scheduler node configured to fire once daily at the switch time, connected to a Connection Action node that runs the switcher's program-input action.
- Best fit: workflow. The trigger is a schedule, not a press: the one thing only a workflow can start from.
- Close second: a button with the same action. This is the right, simpler choice the moment a person is actually there to press it: build the workflow only for the part that must happen with nobody present. If the same swap should also be recallable as a saved routing configuration for a returning show, point the workflow's internal action at Execute Routing Preset instead of a raw connection action, so the same Preset stays capturable, reusable, and up to date the way Create and update a routing Preset describes.
Where to go next#
