Bulk Scheduled Publishing in DATO CMS

I’m currently facing an issue with DATO CMS – I need to schedule the release of multiple changes simultaneously, but the current process only allows for single record publishing. Additionally, with each publish, the build trigger is fired, causing inefficiencies in the build process.

Is there a feature or workaround for bulk publishing multiple changes across various records simultaneously, without triggering a build for each individual record? Any insights or tips on streamlining this process and managing build triggers more effectively would be greatly appreciated.

Thank you in advance!

EDIT: Actually, please see the next post instead. It has an easier and more reliable workaround.

This blurred post lists several other inferior workarounds, just in case. But my recommendation is to use the one in the next post.

Unfortunately, I don’t believe we have that functionality built-in, but there are a few workarounds I can think of…


Option 1: Incremental builds
What framework are you using for your frontend?

If it’s Next.js or something similar, you should be able to use Incremental Static Regeneration (Pages router) or Data validation (App router) to just rebuild the affected page or component, instead of the whole app. IMO that would be the cleanest route and not require any changes to your workflow or build triggers.


Option 2: CMA API

Would you be able to make an external script (or maybe plugin) that does the bulk publishing for you using the Content Management API? Publish items in bulk - Record - Content Management API

You can run it on a cron job, or maybe a serverless worker on a schedule?


Option 3: Manually publish

In the dashboard, you can change the build trigger to ignore scheduled publications:

Then when you’re ready, you can manually start a build in the UI.

You can also semi-automate this by creating a separate model, let’s call it “Release groups”. Make a record in that group and have it scheduled publish a few minutes after all the other ones:

Use a webhook:

To trigger your build via the CMA API.

Roundabout, I know =/


Option 4: Custom webhook on a build debounce (not recommended)

This is probably overkill and fragile. I wouldn’t recommend this, but it most closely matches your original request so I’m mentioning it just in case…

Instead of a build trigger connecting directly to Vercel/Netlify/etc. and building on every publish, you can make it a custom webhook request to an external handler that you’d have to write. That handler could receive X number of build requests over time, but debounce them (like keep a record in an external database or key-value store) and only publish a maximum of once every 5 min/1 hour/whatever you set.

(Or alternatively, just have it re-build every hour on a timer. Maybe add a simple diff to see if it detects any changes, like by hashing a graphQL response.)

Again, this isn’t recommended… it introduces a lot of unnecessary complexity and fragility.


I know none of these are simple solutions, but might any of them work for you? If not, I’m afraid it might be a Feature Request instead?

@claudio.gebbia , I thought about this some more, and I think there is an even simpler solution: Using a linked records inside a master record, and publishing only the master record on a schedule. I think that would be simpler than any of the above options?

Example:

I have two models, both with drafts enabled:
image

posts are what I want to schedule publish in bulk. But I don’t actually want to set it on each one.

Instead, I create a separate model for this purpose. Let’s call it bulk_publishing_group:

Its schema is very simple. In my example I added a title field for clarity, but really it only needs one field, a “Multiple links” field with its validations set to “Publish also the referenced records”:

Then, I create a new record of bulk_publish_group and just link to all the posts I actually want to schedule. Save that record and then set a scheduled publish date ONLY for the bulk_publish_group, not the individual posts:

Because of the validation we previously set, once the bulk_publish_group record publishes, it will automatically publish all the other ones too:

But because there was actually only one scheduled publish (on the bulk_publish_group, the build trigger only fires once:

Does that work for you? It should be simpler and cleaner than the above options.

@roger This looks like a valid solution thank you very much, I will try it out ASAP and let you know if it worked.

1 Like

It works partly. Imagine we want to replace a whole page including updating the navigation:

bulk-publish-goup referencing
→ the new page (with status “draft”)
→ navigation item (status “unpublished changes”)

In my case, the new page is published correctly, while the navigation item stays in the “unpublished changes” state.

Main reason I think is the behavior of the setting:

When a publishing is requested and this field references some unpublished records:
“Publish also the referenced records”

This didn’t cover the state “unpublished change”, right?

It should do that. Is navigation item related to bulk-publish-group, or is it a relationship to page? If the latter, maybe page needs that same “Publish also the referenced records” setting applied to its relationship field to navigation item?

If that’s not the case, could you please send us a link to the record or schema in question? (You can DM me here or email us at support@datocms.com).