Support Multiple Scheduled Publishes on a Record

Hi Dato team!

It would be great to support multiple scheduled publish actions on a single record.

Currently, scheduling works well for a single future publish, but we’ve run into situations where editors would like to prepare several future updates to the same piece of content in advance.

For example:

  • Homepage hero changes throughout the week

  • Rotating featured content

  • Time-sensitive campaigns

  • News or editorial content with planned updates

Today, these changes require someone to manually update and schedule each revision as the previous one goes live.

A possible implementation could be allowing multiple scheduled revisions of a record, where each revision is associated with its own publish date/time. Editors could then prepare a sequence of future updates ahead of time and let Dato handle publishing them automatically.

This would be especially useful for editorial teams managing campaigns, promotions, or homepage content that changes frequently on a schedule.

Hi @danny,

Thanks for the suggestion! Have you seen a good implementation of this anywhere?

It seems like “multiple future revisions” would be quite a difficult thing to change-track across versions without some sort of git-like branching model — which editors probably aren’t too familiar with, no? Our current linear versioning system wouldn’t really work well for something like this (like what happens if they need to make a change to the existing version, or one of the future versions, but not all of them?)

As an alternative, I think some of our customers accomplish a similar thing just by having multiple independent records set to publish at different dates. How you query this is up to you, e.g.:

  • The frontend could do it by itself (by querying a model, sorted by most recent publish date first, limit 1)
  • Or you could encode this into the CMS itself, like:
    • The homepage model could have a multi-link field called scheduled_heroes, linking to a separate model hero
    • Each record in the hero model has its own publish state/date (scheduled or otherwise)
    • When building the home page, the frontend gets all the linked scheduled_heroes and chooses either the most recent one or all the published ones (if a carousel).
    • You can use validation rules to also re-publish the frontpage whenever a linked hero record publishes

This is kinda similar to (but actually the inverse of) the “bulk publishing” workaround: Bulk Scheduled Publishing in DATO CMS - #3 by roger

Would that work for you?

Otherwise, could you please help us think through some implementation examples here, like any you have in mind or that you’ve seen in the wild? The branching/forking model in particular seems quite difficult to reason about… what’s a clean way to do that?

One of my colleagues pointed out a feature like this in a certain well-known CMS :sweat_smile::

There, it seems they just choose to accept the inherent limitation of a linear, non-branching history:

If future versions are scheduled and you update the current version of an entry, upcoming scheduled versions are not automatically updated. Imagine you are changing the field for shipping costs in the current version of the entry from 10 to 5 euros. This change will not be auto-applied to the same field of future versions (e.g. Black Friday).

Is that a limitation your editors are already accustomed to anyway, and not a big deal to them?