Bulk actions & schedules
Walking a 40-sign floor pressing Refresh forty times is not a plan. The event detail page can fire one command at every sign in the event — or at just the ones you picked — and then show you, sign by sign, how it went.
Everything on this page is event-scoped: a wave only ever touches signs registered to the event you're looking at. Only event managers can start one; technicians and viewers can watch (see Who can do what).
Where the bulk actions live
Two entry points, one destination.
The event kebab — the ⋮ button at the top-right of the event detail page, next to Add Sign:
- Bulk update… — push the current sign app build
- Bulk refresh… — reload content now, or on a schedule
The selection bar — tick the checkboxes in the signs table and a bar appears above it: N selected with Refresh, Update, and Clear.
Both routes open the same modal. Nothing fires straight from the menu or the bar — you always get a confirm surface with the counts on it first. The difference is only what's preselected: the kebab starts at all signs in the event, the selection bar starts at your current selection.
Selecting signs
The signs table has a leading checkbox column for event managers. The header checkbox selects everything currently listed — so if you've filtered to Offline or typed in the search box, select-all respects that filter rather than quietly grabbing the whole fleet.
Your selection survives while you work and clears once a wave actually starts. If a sign is unregistered or removed while you have it selected, it drops out of the selection on its own.
Selection is optional
You don't have to select anything. Opening Bulk update… or Bulk refresh… from the kebab targets every sign in the event — which is the common case for a morning content push.
Bulk update
Bulk update pushes the current desktop sign build to signs that aren't on it yet.
The modal opens with the fleet's version spread across the top:
Latest: 1.6.3 (from the update server) — 7 of 40 signs not on latest. 1 ahead of feed (not targeted).
That "latest" number comes from the same update server the signs install from, so the modal can't disagree with what an update actually delivers. While it's being read you'll see "Checking the update server for the latest version…"; the button stays disabled until it resolves, because until then there's no honest count to act on.
The action button names its own scope:
| Button reads | What it means |
|---|---|
Update 7 signs now | Seven signs are behind — those seven get the command |
Every sign is on the latest version | Nothing to do; the button is disabled |
Checking for updates… | The version read is still in flight |
Only signs that are behind are targeted. A sign running a build newer than the update server has is counted and shown as ahead of feed, but never commanded — the sign app won't downgrade itself, so pushing at it would just churn. It's worth noticing rather than hiding: an ahead-of-feed sign usually means somebody installed a build by hand.
Once you confirm:
- Updates roll out 5 signs at a time so a venue's uplink isn't saturated
- Offline signs are skipped, with a receipt in the wave panel
- The wave keeps running server-side — close the modal, close the tab, close the laptop
If the update server can't be reached, the modal says so in red and still lets you fire. It just can't tell you who's behind, so it targets everything in scope and tells you that too.
The auto-update policy
The lower half of the same modal is the event's auto-update policy — a single Arm / Disarm toggle, with an Armed badge when it's on.
While armed, any sign claimed into this event reporting a different version is told to update. Signs already claimed are left alone — use Bulk update for those.
Two things about this are deliberate and worth internalizing:
There's no version to pick. The update server holds exactly one current build, and that's what any update installs. Arming the policy means "match the update server" — nothing more. A stored version target would be a number the devices ignore, so there isn't one.
It fires on claim and link only — never on reconnect. A sign that drops and comes back mid-keynote will not surprise-restart itself. That's the trade: an armed policy gets new signs current as they're provisioned, and it deliberately does not keep already-claimed signs current. Bulk update is the tool for those.
The tech doing the claiming isn't left guessing either — the claim success screen in the mobile app tells them the sign is about to restart on purpose and needs nothing from them.
Disarm before you roll a build by hand
If you're deliberately staging a specific build across a fleet — a pre-event image rollout, a re-claim sweep after a hardware swap — disarm the policy first. Otherwise each claim races your rollout with an update to whatever the update server currently serves. Re-arm when you're done.
Bulk refresh
Bulk refresh reloads the assigned content on many signs at once. The modal has two tabs — Now and Scheduled.
Now
Refresh 40 signs now does exactly that. Refresh is the lightest command there is, so refresh waves aren't throttled the way updates are — every online sign in scope gets it. Offline signs are skipped, and the wave keeps running server-side if you close the page.
This is the standard "content team just republished, push it everywhere" move.
Scheduled
The Scheduled tab holds standing refreshes for this event: "reload every wall at 07:00, every morning of the show."
Press Add Schedule and you get three choices:
- Time of day —
HH:mm - Repeats — Every day or Once (plus a date)
- Which signs — All signs, or your current grid selection (this picker only appears when you have signs selected)
Each armed schedule lists as a row: the time, a badge reading Every day or Once — 2026-03-13, and a scope badge reading All signs or 12 signs. Remove deletes it after a confirm.
How schedules actually behave:
| Behavior | Detail |
|---|---|
| Timezone | Times are evaluated in the event's timezone, not yours and not the sign's. Setting one is a hard prerequisite — see below. |
| Only while active | A schedule fires only while the event is in active state. Nothing runs before the start date or after the end date. |
| Late-fire grace | If the scheduled minute is missed, it still fires up to 10 minutes late. Past that it's skipped for the day rather than firing at the wrong time. |
| One-shot expiry | A Once schedule disarms itself after it fires — or once its day passes without firing. |
| Scope is re-checked at fire time | A scoped schedule is intersected with who's actually in the event when it runs, so a sign that left the event is dropped instead of being commanded out of an event it's no longer in. |
Scheduled refreshes show up in the wave panel like any other wave, so the morning after you can see exactly which signs took it.
Schedules need the event's timezone
If the event has no timezone set, the Scheduled tab offers a Set a timezone link into the event's edit form instead of the Add Schedule button. Set it once and scheduling unlocks. See Your first event → Timezone.
The wave panel
Every bulk command creates a wave, and the wave panel is where you watch it drain. It slides open when you start one, and you can reopen it any time from the Wave: 12/40 Running button beside the Signs heading.
The panel's header gives you the shape at a glance — Update wave — 12/40 plus a Running / Complete / Canceled badge — followed by a summary line of whatever's non-zero: 9 succeeded · 1 failed · 2 skipped.
Below that, one row per sign:
| Status | Meaning |
|---|---|
| Queued | Waiting for a slot |
| In progress | Command sent; the sign hasn't answered yet |
| Succeeded | The sign confirmed it |
| Failed | The sign answered with an error — the reason shows under the sign's name |
| Timed out | No answer in the command's window |
| Skipped | The sign was offline when the wave reached it |
| Canceled | The wave was canceled before this sign started |
Two actions sit in the footer, for event managers:
- Cancel wave (while running) — signs already updating finish; queued signs never start
- Retry failed (3) (once the wave has ended) — re-fires at just the failures and timeouts
One wave per event at a time. While one is running, the bulk buttons disable with "A wave is already running". Wait for it to finish or cancel it.
If you reload the page, the panel recalls the last wave for that event — including a finished one with failures still worth retrying.
Who can do what
| Action | Manager | Technician | Viewer |
|---|---|---|---|
| Select signs, open the bulk modals | ✅ | — | — |
| Start a refresh or update wave | ✅ | — | — |
| Arm / disarm the auto-update policy | ✅ | — | — |
| Add / remove a scheduled refresh | ✅ | — | — |
| Cancel a wave, retry failures | ✅ | — | — |
| Watch a running wave | ✅ | ✅ | — |
| Per-sign commands on a sign detail page | ✅ | ✅ | — |
Technicians deliberately keep full sight of a running wave. When a manager fires an update from the office and a tech is standing at the wall watching screens go dark, "is this supposed to be happening?" should be answerable from the phone in their hand. Their own per-sign commands are unaffected either way.
Org owners and admins carry event-manager privilege implicitly — see Roles & permissions.
When to reach for what
| Situation | Use |
|---|---|
| Content team republished; every wall needs it | Bulk refresh → Now, all signs |
| One booth's wall is stale | Per-sign Refresh Content (Remote control) |
| Multi-day show; walls should start each morning fresh | Bulk refresh → Scheduled, Every day |
| Provisioning 40 signs the week before a show | Arm the auto-update policy, then claim |
| Fleet is mid-show and mixed-version | Leave it alone until a break, then Bulk update the behind signs |
| A handful failed in the last wave | Retry failed in the wave panel |
The last row of that table is the one people get wrong. An update restarts the sign — see Stability over features for why "we'll update everything Tuesday morning before doors" beats "we'll update it now."
What's next
- Remote control — the same commands, one sign at a time, and what each does on the kiosk
- Monitoring & health — reading a sign's health before and after a wave
- Live event checklist — where a fleet-wide update belongs in the run of show