# Choose a control method

> Compare a button action stack, a routing Preset, a Cuelist and a workflow to decide which one fits a task before you build it.

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 runs its own actions when someone presses it. It can run actions together or one after another ( ActionGroup ), choose between actions based on a condition ( ActionLogic ), and repeat actions while a condition holds ( While ). Use a button on its own when one control doing its own job 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 list of cues that run in a set order. It remembers which cue is next, and it doesn't belong to any one position or button, so any position can control it. Each cue holds its own actions, with the same ActionGroup , ActionLogic and While options as a button. Use a Cuelist when steps must happen in a set order, or when many similar actions are easier to manage as rows in one list than as 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, but an unlicensed Free installation does have limits. A single Cuelist is capped at 32 cues in total, and a workflow at 32 nodes. The Routing system only routes the first 16 source groups and the first 16 destination groups; anything beyond those is blocked, so a routing Preset can only take routes between those 16 sources and 16 destinations. A button's own action stack has no equivalent limit, including when its actions use a router connection's module actions directly instead of the Routing system. 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 ( ActionGroup , ActionLogic and While 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. Swap camera inputs on a schedule 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 Create your first button for a direct action and feedback. Create and update a routing Preset to save and recall a set of routes. Understand Cuelists to build a determined show order. Understand workflows to automate from a trigger other than a press, or add branching logic.