Studio automation without replacing your stack:
How rundown cues can drive the tools you already use

Published 14 October 202610 min readBy the Fabl team

Most production teams build the same show several times: in a document, in a rundown, again as switcher, graphics and audio moves, and once more after the show for publishing and the archive. Every handoff costs time and leaves room for mistakes. You want studio automation, but you don't want a forklift project that replaces equipment that still works well.

You don't have to replace anything. With Fabl, you automate from the rundown and keep your gear.

The short answer: Studio automation without replacing your stack means adding a control layer on top of the equipment you already run, instead of buying a new automation system with its own devices. The rundown becomes the trigger: when a rundown event happens, such as an item completing, a configured action fires in a connected tool, like a switcher cut, a publishing step or an archive handoff. That's how we built Fabl. Approved briefs and scripts flow into a timed rundown, rundown events trigger configured actions in supported studio tools, and your shared plan lives in the cloud while Fabl Studio Agent executes device commands on your local production network.

What studio automation means today

In live and broadcast production, studio automation means letting a planned sequence of events, usually the rundown, drive the actions operators would otherwise do by hand: cutting cameras, firing graphics, opening microphones, rolling clips and starting recordings. Done well, it lets a small team run a consistent show.

From full gallery automation to a control layer

Broadcast studio automation has traditionally meant a dedicated, template-based gallery automation system, with its own device drivers and servers in the control room.

We built Fabl around a different idea: a control layer. Fabl doesn't bring its own devices or ask you to replace your gallery. It sits on top of the tools you already have and talks to them through the control interfaces they document, such as OSC, TCP, UDP, HTTP, WebSocket and local files. Events in your rundown trigger configured actions in those tools.

That makes Fabl a fit for teams that want to automate step by step, keep their current mix of vendors, and extend automation beyond the gallery into publishing and archive.

Rundown, NRCS and automation: who does what

These three terms often get mixed up. Here is how they usually divide the work:

Layer	Main job	Typical contents	Who uses it
Rundown tool	Plans and times the show	Items, segment durations, backtiming, owners, running order	Producers, directors, the live team
NRCS (newsroom computer system)	Manages editorial content across the newsroom	Stories, scripts, wires, assignments, rundowns	Editors, journalists, producers
Studio automation system	Turns the plan into device actions	Rules that map rundown events to switcher, graphics, audio, playout and recording commands	Directors, technical leads, operators

What matters is whether information flows between the layers, or gets re-keyed at every step. Fabl connects writing, the live rundown and studio automation in one workflow, so the story you approved is the story that drives the show.

Why rip-and-replace stalls automation projects

When automation means replacing the studio, projects slow down or stall. The reasons are usually practical, not technical:

Sunk cost. Switchers, graphics engines, consoles and playout servers are big investments with years of life left.
Retraining. Directors and operators have built muscle memory on their current tools. A new system means new workflows, new terms and a period of lower confidence on air.
Long cutovers. A live operation can't simply stop, so migration means parallel running and lots of rehearsal.
Vendor lock-in. When automation is tied to one vendor's ecosystem, your later choices about switchers, graphics or playout narrow.
Scope creep. "Automate the opening sequence" turns into a rebuild of the whole gallery.

We designed Fabl's control layer to sidestep all of this. You automate the handoffs that hurt most, keep the equipment and skills you have, and expand from there. Your work moves on. Your tools stay in place.

How rundown-driven automation works in Fabl

Rundown automation follows a simple idea: your rundown already describes what should happen and when, so let it trigger the matching actions. In Fabl, that comes down to three parts.

Cues and events

Producers advance items in Studio Mode, taking each one live as the show runs. Configured automation rules listen for the matching rundown event. You choose the relevant event as the trigger, for example "when a rundown item completes", and Fabl reacts when it happens.

Configured actions

Each rule pairs a rundown event with an action: a supported device command, a system update or a downstream workflow action. Here is a simple switcher automation rule in Fabl:

Rule:     When the live segment ends
Trigger:  Rundown · When a rundown item completes
Action:   Main Switcher · Execute device command · Cut
State:    Ready → Running → Done

This is what it looks like to automate switcher from rundown. When the producer moves past the segment, the cut happens without anyone pressing a separate button on another surface. The same pattern works across device categories: cut to camera 2, roll the opening graphics, open the presenter's audio, start the recording. You run the room from the rundown instead of operating each system separately.

Need to reach something beyond a device? Custom webhooks let a rundown event call any HTTP endpoint, and publishing workflows carry approved outputs onward after the show.

Feedback to the team

Automation only earns trust when your team can see what happened. In Fabl, each action moves through visible states: Ready (armed and waiting for its event), Running (the command has been sent) and Done (the action has completed). Fabl Studio Agent returns available device state, and that feedback appears in Fabl wherever the integration supports it. Your director keeps the trigger, the command and the result in view, without checking three screens to confirm a cut.

Plan in the cloud. Execute on site.

A common question about studio automation software is where it runs. Planning and execution have different needs, so Fabl splits them in a hybrid cloud and on-prem model:

Planning belongs in a shared space. Producers, editors and directors need to see the same rundown, timing and ownership, often from different locations. Fabl keeps your shared production plan in the cloud.
Device control belongs on the production network. Switchers, consoles and playout servers sit on a local network. Fabl Studio Agent connects your configured devices and executes supported commands right there on the production network, keeping the control path short and local.

Plan together. Execute on site. Your team collaborates on one plan, and the commands run where your equipment lives.

Want to see how Studio Agent fits your room? Talk to us about your setup.

Beyond the live show: the story lifecycle

Most broadcast studio automation stops at playout. But the rundown isn't where your story begins or ends: before the show there are briefs, scripts and approvals, and after it there's publishing and archiving.

Fabl treats automation as one stage in a connected newsroom workflow, with five stages: brief and script, live rundown, studio automation, publishing, and archive. Each stage carries the context of the one before it:

Brief & script (before production). Ideas, research, versions and approvals sit next to the script in one story workspace. Your team writes together with comments, presence and version history, and only approved work moves into production.
Live rundown (live). The approved script becomes a timed rundown without copying or exporting it, complete with timing, owners, assets and production state.
Studio automation (live). Rundown events trigger configured device actions, and feedback comes back to the team.
Publishing (after). Approved outputs move on through configured channel delivery workflows.
Archive (after). Final assets, metadata and history are kept, so the production record stays connected to where the story began.

Nobody rebuilds the production record at a handoff. The same plan that drove the cut carries on into publishing and archive.

Checklist: is your stack ready?

Work through this list with your technical and editorial leads. It's the same list we use when we plan a rollout with you.

1. Inventory your devices and tools

List every system involved in a typical show: switcher, graphics, audio, playout and media servers, recorders, PTZ cameras, streaming encoders, publishing and archive.
Note the newsroom or rundown system you use today, if any.

2. Check how each one is controlled

Does it expose OSC, TCP or UDP commands, HTTP, WebSocket or another documented control interface?
Does it report state back, such as tally, playback status or recording status?
Check your tools against our integrations. You'll see which tools are listed, which have public setup guides, and which actions and feedback each documented integration offers.

3. Decide who owns the rules

Who creates and edits automation rules: technical lead, director, senior producer?
Who approves changes before a live show?

4. Plan testing and rehearsal

Start with one or two high-value handoffs, such as the show open or segment transitions.
Rehearse with real equipment on the production network before going live.
Agree what "done" looks like for each action and how the team will see it.

5. Define your manual fallback

Because your existing equipment stays in place, every automated action keeps a manual equivalent on its original control surface. Make sure operators know it.
Agree how the director takes control during breaking news or when the rundown changes late.

6. Look beyond the gallery

Which after-show steps (publishing, clipping, archive, metadata) are rebuilt by hand today?
Could the same rundown events trigger them?

Missing a device from our list? Bring us your setup. Tell us which device and production handoff you need to connect, and we'll review the available integration path with you.

Keep your stack. Run it as one.

We built Fabl for teams that want to stop rebuilding the same production across documents, rundowns and control tools. Fabl doesn't replace your studio tools. It connects the handoffs between them.

Write: Keep briefs, feedback, versions and approvals beside the script, then carry agreed work into production.
Run: Keep timing, owners, assets and late changes in one live rundown, and advance the next cue in Studio Mode.
Go Live: Use rundown events to trigger configured device, publishing and archive actions through Fabl.
Cloud + local: Shared planning in Fabl, with Fabl Studio Agent executing supported device commands on your local production network.
65 listed tools across 10 categories, from vision mixers and cameras to audio, graphics, playout, streaming and show control.

What sets Fabl apart is the full story lifecycle, from brief to archive, with your production record connected the whole way through.

Check your tools against our integrations →

Want to see it with your own workflow? Show us the handoff you want to improve, or create an account and explore Fabl yourself.

FAQ

What is studio automation in live and broadcast production?

Studio automation lets a planned sequence, usually the rundown, trigger the device actions operators would otherwise perform by hand, such as camera cuts, graphics, audio and recording. Fabl does this as a control layer on top of the equipment you already run.

Can you automate a studio without replacing your existing switcher, graphics or playout?

Yes. Fabl connects to the tools you already run through their documented control interfaces and lets rundown cues trigger configured actions in supported studio tools already in your stack. Check your devices against our integrations, or tell us about your setup.

How do rundown cues trigger actions in studio devices?

In Fabl, an automation rule listens for a rundown event, such as an item completing, and then runs a configured action in a connected device, for example "Main Switcher · Execute device command · Cut". The action moves through visible states (Ready, Running, Done), and returned device status appears wherever the integration supports feedback.

Do you need on-prem automation servers, or can planning run in the cloud?

With Fabl, planning runs in the cloud while device control stays on site. Your shared production plan lives in Fabl, and Fabl Studio Agent executes supported device commands on your local production network.

Can the same rundown drive publishing and archive after the show?

Yes. Fabl treats the live show as one stage in a longer story lifecycle. Stories move from brief and script through the live rundown and studio automation into configured publishing and archive workflows, without rebuilding the production record. Create an account to explore the workflow yourself.