A price list, a class timetable, a production board and a staff rota all have the same shape: a table that changes often, wrapped in a design that does not. easyCMS handles that with DataSets, and it is the most useful thing in the product that almost nobody asks us about. Build the layout once, hold the content in a table, and updating a screen becomes editing a row instead of redesigning a slide.
If you have ever exported a menu to a JPEG, uploaded it, and then done the whole thing again because one price moved by 20 cents, this is the article for you.
The idea: the layout is the design, the DataSet is the content
Most people build signage the way they build a poster. The design and the content are the same object, so any change to the content means going back to the design tool, changing a number, exporting, uploading and rescheduling. Do that once a quarter and it is fine. Do it three times a week and it quietly becomes somebody’s job.
A DataSet splits the two apart.
The DataSet is a table stored in the CMS. Columns, rows, nothing exotic. It holds the facts: item names, prices, class times, line numbers, shift names.
The layout is the design. Fonts, colours, spacing, your logo, the background, the region the table sits in. You build it once and you do not touch it again.
The DataSet widget is the join between them. It sits in a region of the layout, points at the table, and renders the rows using a small template you style once.
After that, changing what is on screen means editing a cell. The design cannot drift, because nobody is opening it. That is the real benefit, and it is as much about consistency as speed: fifteen edits to a table produce fifteen correct screens, whereas fifteen edits to a poster produce fourteen correct screens and one where somebody used the wrong blue.
The full walkthrough with screenshots lives in dynamic content with DataSets. What follows is the shape of it, plus the parts that decide whether this works for you.
Building one, in six steps
1. Create the DataSet and name it. Name it after the thing, not the screen. “Drinks menu” ages better than “Layout 3 top region”, because in a month it will be feeding two layouts.
2. Define the columns. This is the only step that repays real thought, and the one people rush. Each column is one fact: name, price, category, start time, status. Resist the temptation to put a whole formatted line into a single column, because a column you cannot filter or sort on is just a picture of text. Split “Espresso 2.50€” into an item column and a price column and you can later sort by price, hide the expensive things at breakfast, or reuse the same table on a different layout that shows prices in a different position.
3. Add rows, or import a CSV. You can type rows straight into the CMS, or import a CSV. The CSV route is usually how a DataSet starts life, because the data already exists in somebody’s spreadsheet. Export it, tidy the column headings, import it. If your source spreadsheet is the master copy, you keep editing it there and import a fresh file when it changes.
4. Put a DataSet widget in a layout. Open the layout editor, add a region, add a DataSet widget, point it at your table. It behaves like any other widget: it can share the screen with a video, a clock, an image or a ticker. See creating layouts if you have not built one yet.
5. Style the template once. The widget renders each row through a small template you control: which columns appear, in what order, and how they look. Get one row looking right and every row looks right, including the ones that do not exist yet. This is the step that makes the difference between a table that looks like a spreadsheet on a wall and a menu board that looks designed.
6. Filter and order. The widget does not have to show the whole table. Filter it to a category, a status or a date, and order it by whatever column makes sense. This is what lets one table drive several screens: a drinks board and a food board can be the same DataSet, filtered two different ways.
Tip Build the layout with the table half full. A design that looks right with four rows and breaks with eleven will break on the day you are busiest. Add rows until it overflows, and find out where the ceiling is before a customer does.
Four worked examples
A cafe price list
The classic case, and the one that pays for itself fastest. A table like this:
| Category | Item | Price | Available | Sort |
|---|---|---|---|---|
| Coffee | Espresso | 2.50€ | Yes | 1 |
| Coffee | Flat white | 3.40€ | Yes | 2 |
| Coffee | Filter | 2.80€ | Yes | 3 |
| Food | Croissant | 2.20€ | Yes | 1 |
| Food | Soup of the day | 5.90€ | No | 2 |
One DataSet, two layouts. The drinks board filters to Category = Coffee, the food board filters to Category = Food, both filter out anything where Available is No, and both order by the Sort column so you decide what sits at the top rather than the alphabet deciding for you.
When the supplier price moves, someone changes one cell. When the soup runs out, someone flips Yes to No and the line disappears from the board rather than sitting there disappointing people. Nobody opens the design. There is more on the surrounding decisions in our guide to digital menu boards and in digital signage for restaurants and bars.
A gym class timetable
Columns: Day, Start, Class, Studio, Instructor, Spaces. One row per class per day, so a week is maybe sixty rows, imported once from the timetable spreadsheet you already keep.
The screen in reception filters to today and orders by start time. The screen outside studio two filters to Studio = 2. The same table, two different jobs, and no second copy to fall out of step with the first.
The honest part: nothing counts down the spaces for you. If the Spaces column is going to be wrong by ten o’clock, do not put it on the wall. A timetable that is always right is worth more than a booking count that is usually stale. More on the wider setup in digital signage for gyms and fitness.
A factory production board
Columns: Line, Shift, Target, Actual, Status. Five rows, one per line, updated by the shift supervisor.
This is where DataSets earn their keep in a way a poster never could, because the content changes several times a day and the design must never change at all. Filter to the current shift, order by line number, and style the Status column so the words are large enough to read from the far end of the floor.
Be clear-eyed about the input though. Somebody has to put the numbers in, or somebody has to export a CSV from the production system and import it. It will not arrive on its own. Decide who owns that before you mount the screen, because a production board showing yesterday’s numbers is worse than no production board. Digital signage for manufacturing covers the rest of the deployment.
A staff rota
Columns: Date, Shift, Name, Role, Site. Filter to today and tomorrow, order by shift start, and put it on the screen in the back corridor or the staff room.
This one has a privacy dimension worth a minute of thought. A rota on a wall is personal data on display, so keep the columns to what the screen actually needs. Names and shifts, not phone numbers, not addresses, not anything you would not print and pin up. That is practical guidance rather than legal advice, so check it against your own data protection obligations. On the 49€ account and on PRO, anyone with the login can edit any table, because users, groups and permissions are an Enterprise feature. If several people need edit access with different scopes, that is the tier that does it. See also digital signage for internal communication.
What DataSets cannot do
Now the limits, because this is the part most articles skip and it is the part that decides whether you are about to waste an afternoon.
It is a table you maintain, not a live connection. A DataSet is data you own, held in the CMS, updated by a person or by importing a file. It does not reach out to your till system, your booking platform or your ERP and pull today’s numbers. If you need genuinely live figures with nobody in the loop, a DataSet is the wrong tool and you should read the next section.
There is no Google Sheets connector. People assume this one, and it is worth stating plainly. You cannot point easyCMS at a Google Sheet and have it follow along. Your Google Sheet can be the master copy, but the trip from it to the screen is an export and an import that a human performs. That is fine for a menu that changes weekly. It is not fine for a number that changes hourly.
Changes are not instant. Players pull content on their check-in interval, so an edit reaches the wall on the next collection rather than the moment you save. Seconds to minutes, not milliseconds. Do not build a live queue counter out of this.
There is no charts widget. A DataSet renders as a table of rows, not as a bar chart or a graph. If the requirement is a visual chart, that is a job for the webpage widget or a dashboard embed, covered in dashboards for digital signage.
Somebody still owns the data. The technology removes the design work, not the data-entry work. Every successful DataSet deployment we have seen has a named person whose job includes keeping the table right, and every failed one does not.
When a live source is genuinely the answer
If the data must be live and unattended, the honest recommendation is the webpage widget rather than a DataSet. Point a region at a URL and the player renders that page as part of the layout, so whatever the page shows, the screen shows. See webpages and embedded content.
That brings its own problem, and it is a bigger one than people expect: authentication.
A player is an unattended device on a wall. It has no keyboard, nobody sits at it, and it cannot answer a login prompt, click through a two-factor challenge or re-consent when a session expires. Point it at a private dashboard and the screen will show a login page, usually at the worst possible moment. The workable routes are a page that needs no login from that network, a read-only public or tokenised share link that your provider supports, or an internal page your own team publishes for exactly this purpose. Anything that expects a human to sign in will fail, and it will fail silently.
Watch out Live embedded content is also the first thing to break when the network does. A cached image keeps playing for days; an embedded page shows an empty rectangle within minutes and does not look broken. We covered which content survives an outage in digital signage without internet.
The practical answer for most people is a mix. Use a DataSet for the ninety per cent that changes daily or weekly and needs to look designed, and reserve the embedded page for the one region that genuinely has to be live.
What this costs, here and elsewhere
DataSets are included on every easyCMS account. There is no data tier, no add-on, and no per-screen surcharge for using them. The 49€ account has them, and so does everything above it.
That is not universal. OptiSigns’ equivalent tiers are all recurring: its published Pro Plus price is $15 per screen per month billed monthly, or $13.50 per screen per month billed annually, checked September 2026. Compare the running total:
| Screens showing data-driven content | easyCMS, paid once | OptiSigns Pro Plus, per year at the monthly rate |
|---|---|---|
| 1 | 49€ (account, one licence included) | $180 |
| 5 | 313€ (49€ + 4 × 66€) | $900 |
| 25 | 1,883€ (PRO 299€ + 24 × 66€) | $4,500 |
Competitor pricing checked September 2026 from the vendor’s own page. We do not convert currencies, so read the columns side by side rather than subtracting one from the other. The easyCMS column is the price when the licences go through checkout with the account, which is 66€ each rather than 99€. Added later they are 99€, so the same networks come to 445€ and 2,675€. On break-even against OptiSigns Standard’s annual euro price of 7,50€ per screen per month, a first screen pays for itself in roughly six months, each additional screen in roughly nine, and a 25-screen PRO build in roughly ten. Before that point the subscription is cheaper, and we are not going to pretend otherwise.
Two more honest notes. OptiSigns has a genuinely free tier for up to three screens, with their logo on screen and community support only, which easyCMS does not match because we have no free plan and no free trial. And if what you actually want is a live spreadsheet that syncs itself, a platform with a built-in sheet connector is doing something we do not do, whatever it costs. Our fuller comparison is in OptiSigns vs Yodeck vs easyCMS, and the general arithmetic is in pricing.
One small practical advantage worth knowing: a DataSet is text, so it barely touches your storage quota. The 1GB on a standard account is consumed by video and images, not by tables. See storage quota and media uploads if you are working out what fits.
Five rules that keep a DataSet useful
- One fact per column. If you cannot filter or sort on it, it should not be in there as prose.
- Add a sort column. An explicit number column beats alphabetical order and costs nothing.
- Add an availability or status column. Hiding a row is safer than deleting it, and the row comes back when the soup does.
- Design for overflow. Decide what happens at twice as many rows as you have today.
- Name an owner. The table is only as good as the person who keeps it current.
Combine those with scheduling and the same table can drive a breakfast board and a lunch board from one layout, changing by time of day without anyone touching it.
The short version
A DataSet is a spreadsheet that lives in the CMS and feeds a design you built once. It suits price lists, timetables, production boards and rotas: anything where the numbers move and the design must not. It is included on every plan, it costs nothing in storage, and it turns a design job into a data-entry job.
What it is not is a live feed. There is no Google Sheets connector and no automatic sync, so if the data has to update itself, use the webpage widget and solve the authentication question before you mount anything. Start with dynamic content with DataSets, and if you are unsure which of your screens should be a table and which should be a live page, email info@myeasycms.com and describe the content.
Related reading: dynamic content with DataSets, digital menu boards, features.