Real-time showflow updates: getting a change onto every device
A running order that is right on one screen and wrong on five others is worse than one everybody knows is out of date. This is how live updates actually behave on real venue networks.
Why copies drift
The running order exists in more places than anyone tracks: the show caller's screen, a stage manager's tablet, the graphics operator's second monitor, a printed sheet at front of house, and the version someone exported to PDF on the train. Change one and every other copy is wrong until a human remembers it exists. Real-time updating is not a convenience feature; it is the removal of that reconciliation step.
The dangerous state is not "out of date". It is "partly up to date". A crew that knows the sheet is from this morning will check before acting. A crew that believes the sheet is live, when three of the seven devices did not receive the last change, will act on it.
What real-time means
Used precisely, it means a change made in one place appears on other connected devices without anyone refreshing, reopening or re-exporting anything. Used loosely, it can mean a page that polls every thirty seconds, which is a materially different promise during a show.
The distinction that matters operationally is not the latency figure. It is whether a device can tell you that it is currently connected. A screen showing stale data indistinguishable from live data is the failure mode; a screen that says plainly that it has lost contact lets the person holding it fall back to comms.
- Push, not poll
- The change is sent to connected devices when it happens, rather than found the next time a device asks.
- A visible connection state
- The single most important element on a live device. Connected, reconnecting, offline — never ambiguous.
- Reconnect and catch up
- A device that drops for ninety seconds must come back to the current state, not to the state it left.
- One source
- If the tablet is reading an export rather than the record, none of the above helps.
What happens offline?
Assume the network will fail, because at venues it does. Basements, marquees, exhibition halls with ten thousand phones on the same guest wifi, and back-of-house corridors are all reliably bad. Plan for the device that loses contact rather than for the one that does not.
The practical mitigations are unglamorous and they work: put critical positions on hardwired ethernet where the venue allows it, keep a cellular fallback for at least the show caller, print a paper running order at the last responsible moment and mark it clearly with the time it was printed, and rehearse the failure — actually pull the network in rehearsal and watch what the devices do.
The printed sheet is not an admission of defeat. It is the fallback, and the timestamp is what makes it safe: a sheet marked with the moment it was printed can be reasoned about, while an undated printout cannot.
Who is allowed to change it?
This is a discipline question that software can support but cannot answer. During a show, one person edits the running order. Everyone else raises the change to that person over comms.
The reason is not politics. If two people can move the same item, the record stops being a shared truth and becomes a negotiation, and the crew loses the one thing that made it worth trusting. Decide who holds the pen before doors, say it out loud in the briefing, and make sure the rest of the team know how to reach them.
How EventBlok fits
Everything above applies whatever you run the show from. This is EventBlok specifically.
In EventBlok the showflow is a live view of the same programme the agenda publishes rather than an exported document, so there is no version to distribute and nothing to reconcile. A change to a session moves its cues with it, and the published agenda, speaker pages and signage views read the same record.
For how that propagation works across surfaces, see how a change reaches every screen; for the editorial side of announcing changes to attendees, see managing live agenda changes.
Common questions
What does real-time mean for a showflow?
That a change made in one place appears on other connected devices without anyone refreshing, reopening or re-exporting. The figure that matters operationally is not latency but whether each device shows its own connection state, because stale data that looks live is the actual hazard.
What happens if the venue network drops?
The device should say so clearly rather than continue showing data that looks current, and it should return to the current state — not the state it left — when it reconnects. Plan for it: hardwire critical positions where you can, keep a cellular fallback for the show caller, and rehearse the failure by actually pulling the network.
Should we still print a running order?
Yes, and mark it with the time it was printed. A timestamped paper sheet can be reasoned about when the network fails; an undated one cannot. Printing at the last responsible moment is a fallback, not an admission that live updating failed.
Who should be allowed to edit during a show?
One person. Everyone else raises changes to them over comms. If two people can move the same item the record stops being a shared truth, which removes the reason the crew trusted it. Decide who holds the pen before doors and say it in the briefing.
Plan the event. Publish the programme. Run the show.
One event spine, many views. Build the programme once, then give every person the right live view of it.