How to publish event schedule changes without rebuilding the site

Model the programme as entries

In Anticode's dashboard, create a CMS collection named something like sessions. Collections have typed fields, so each session can carry:

• Title (text): the first text field becomes the entry's title
• Day and start time, end time (text or date, written one way throughout, for example "Sat 10:30")
• Room or stage (text)
• Speakers (text)
• Description (rich text, for anything longer than a line)
• Status (text): left empty normally, or "Moved", "New" or "Cancelled"

Each entry also gets its own page on the published site, at /sessions/<slug>, with the full list at /sessions/. These pages come from the collection when someone opens them, so a saved edit shows up there straight away.

Before the event: set the rules

1. Name one agenda owner and one deputy. Everyone else sends changes to them rather than editing.
2. Give both their own seats if the site is in a Team workspace. Members can edit and publish but can't delete the project or take the site down, which suits this job. Because the site may collect registrations or enquiries, the account owner and the person publishing need two-factor sign-in turned on.
3. Decide the freeze point for the printed programme. After it, changes appear online and on a board at the venue, not in print.
4. Add a "Changes" section near the top of the agenda page, listing the latest changes in one line each, newest first.

Making a change on the day

Why the publish in that sequence? The collection's own pages read the latest entries as they're served, but sections that are part of the site's main pages, such as an agenda grid on the home page or the Changes section itself, are written into the page when you publish. A quick publish brings them level. The publish checks run each time, and take seconds.

Telling attendees

A website change only reaches people who look. For anything that affects many attendees (a keynote moves, a building closes), send a message from your registration or email tool as well. Anticode doesn't email your attendees. Keep the message short: what changed, the new time and place, and a link to the agenda.

What goes wrong

• Two people edit the same session. One owner prevents it; the deputy edits only when the owner hands over.
• The time format drifts (10:30, 10.30am, half ten). Agree one format before the first entry.
• A cancelled session is deleted and people who saved its link hit a missing page. Mark it "Cancelled" and leave the entry for the rest of the event.
• The home page grid shows the old time. Someone saved the entry but didn't publish. Publish again.

How you know it's working

Volunteers at the help desk check the website rather than a printout, and it's right. Every change reaches the site within ten minutes of being agreed. Nobody turns up to an empty room.

Limits

There's no scheduled publishing, no push notification to attendees, no personal agenda builder for visitors, no calendar files per session and no translation into other languages. Pages run no scripts, so there's no live "now playing" indicator. See the event agenda page builder, CMS collections and running a call for speakers.

Questions people ask

Do I need to rebuild the site to change a session time?

No. Edit the entry in the dashboard. Its own page updates at once; publish again for any agenda section on the main pages.

Can volunteers update the agenda?

Give the agenda owner and a deputy their own seats. Other volunteers send changes to them, which keeps one version of the truth.

How should I publish event schedule changes so people notice?

Edit the session, mark its status, add a line to a Changes section at the top of the agenda, and post the same change in the event's own channels.