Digital signage scheduling controls what content appears on which screens, when. A schedule combines playlists (ordered sequences of content), time rules (when to play), and conditional triggers (data-driven changes). Good scheduling makes signage fully autonomous — no human presses "play" each morning. Bad scheduling means someone manually updates 500 screens every day.
When to Use Scheduling
- Multiple content zones — morning greetings at 8 AM, lunch menu at noon, KPIs in the afternoon
- Different content per location — Dubai office sees local weather, Riyadh office sees Riyadh weather
- Compliance requirements — regulatory messages must display at specific times for specific durations
- Event-driven changes — conference room shows agenda during meetings, default signage otherwise
How Scheduling Works
Playlists
A playlist is an ordered sequence of content items with durations. Items can be: static images, videos, data-driven widgets, or entire multi-zone layouts. Each item has a duration (seconds), transition effect, and optional priority level.
Time Rules
Rules define when each playlist is active: time-of-day, day-of-week, date range, or specific calendar dates. SpinetiX supports layered rules — higher priority schedules override lower ones. Example: "Show default playlist always → override with prayer times at Adhan → override everything with emergency alerts."
Conditional Logic
Data-driven scheduling responds to external conditions without manual intervention:
- Weather — show cold drinks when temperature > 35°C, hot coffee below 15°C
- Calendar — display meeting agenda when room is booked, wayfinding when free
- Sensor — show queue information when wait > 10 minutes
- API — trigger content changes from your CRM, POS, or ERP system
Emergency Override
A single action pushes critical messaging to all screens instantly, regardless of active schedule. Fire alarm, security alert, evacuation notice — one button, all screens. SpinetiX supports this via API call, Arya Cloud dashboard, or Elementi push. Always test this during deployment, not during an actual emergency.
Key Parameters
| Feature | SpinetiX Capability | Use Case |
|---|---|---|
| Playlist types | Sequential, random, weighted, data-driven | Standard loops, dynamic content |
| Time granularity | Per-minute scheduling | Prayer times, trading hours, shift changes |
| Priority layers | Unlimited priority levels | Default → scheduled → event → emergency |
| Multi-timezone | Per-player timezone configuration | Global deployments across regions |
| Conditional triggers | API, calendar, sensor, weather, database | Automated content without human intervention |
| Emergency override | API/dashboard push, <5 second propagation | Safety alerts, evacuation notices |
Common Mistakes in Scheduling
- Manual scheduling for repeating content. If someone manually updates the lunch menu daily — it will stop working within 2 weeks. Connect the menu data source to a template. Automate everything that repeats.
- No priority hierarchy. When two schedules conflict, which wins? Define priority layers upfront. Emergency > event > scheduled > default. Test conflicts before go-live.
- Forgetting time zones. A global deployment scheduling content at "9:00 AM" without timezone awareness will show morning content at midnight in some locations. Always configure per-player timezones.
- Not testing emergency override. The emergency system must work instantly when it matters. Test it during commissioning, not during a fire drill. CMS scheduling features →