Similar to our recent updates in the Webhooks Activity section, we have also enhanced the Build Triggers Activity view.
Previously, the CMS displayed only the 30 most recent build events.
We have now improved this by providing options to view events from the past weeks, and to apply filters or custom ordering, while also updating the UI to align with the overall design of the CMS.
For quite some time now, you've asked for the ability to insert blocks as inline elements inside the Structured Text field. Actually, it's one of the most requested features on our forum.
Well, here we are 🎉
It's now possible to setup structured text fields and declare which blocks can be added as inline elements in the content.
What’s new?
Stuctured text fields have a new setting that allows to select the types of block that can be used as inline element: that's very similar to what we already have for regular, stacked blocks.
Why does it matter?
Inline blocks open infinite possibilities: from links with custom data to mentions, from hashtags to inline notes... Fantasy is the limit!
And that's just the beginning: Inline blocks can ALSO have structured text fields with inline blocks within: so you can nest blocks 🤯 (with the same limits you have on your plan for stacked blocks).
How do I enable it?
Simply head over to any structured text field’s settings, locate the new "Allow adding Inline Blocks" in the “Validation” tab, and select the blocks you want to make available in the field.
API Changes
From the API perspective, the Dast changed a bit and it now supports inline blocks inside paragraphs and headers. You'll appreciate the difference, of course, only when you start using inline blocks: there's no impact on fields that keep using regular, stacked blocks.
Check out inline blocks in action 👇
We’ve been carrying around an issue for quite some time regarding how we manage SEO fallback data. Because the same fields used for internal previews—Title and Image Preview—are also used for SEO fallback data, it’s been causing confusion and often results in less-than-ideal search engine metadata.
To address this, we’re splitting the two settings and creating a dedicated “SEO Fallback” tab!
What’s new?
We’re removing the overlap between “Presentation” fields and “SEO” fields. Now you can explicitly choose which fields feed into your SEO Title, Image, and Description. These are separate from the fields used for internal previews, giving you more granular control over how your content appears in search results.
Why does it matter?
With dedicated SEO fields, you can optimize exactly how content appears on search engines—without affecting the quick, at-a-glance previews in the CMS. This ensures your internal workflow remains clear and uncluttered, while your SEO metadata stays fine-tuned for external audiences.
How do I enable it?
Simply head over to any Model’s settings, locate the new “SEO” tab, and select the fields you want to use for SEO Title, Image, and Description.
If you want to experiment with all the new presentation fields available, explore the head over the Presentation Tab!
We've introduced two new relationships on the item_type entity: presentation_title_field and presentation_image_field. These relationships are exclusively used for DatoCMS’s internal interface and preview functionality:
presentation_title_field supports fields of type: string, date, date_time, link, text, structured_text, color, lat_lon, integer, and float.
presentation_image_field supports fields of type: file, gallery, link, color, date, date_time, and lat_lon.
At the same time, the existing relationships — title_field, image_preview_field, and excerpt_field — are now dedicated solely to configuring SEO fallback settings. As a result:
title_field no longer accepts fields of type date, date_time, link, text, structured_text, or color. It now only supports string fields.
image_preview_field no longer accepts fields of type link or color. It now only supports file and gallery fields.
These changes only refine the accepted field types and do not affect functionality, as the previously accepted field types were already ignored for SEO purposes and if ie. a model had a date field set as title_field that field is now set as presentation_title_field.
We’ve heard from many of you that it’s tough to quickly grasp what’s inside each record or block at a glance when shown in preview mode —especially when those blocks or records lack text fields.
To address this, we’ve introduced a new approach to displaying previews across the entire CMS: inline blocks, link fields, and even the item index, all benefit from clearer at-a-glance content!
What's new?
First, we’ve aligned how the “Presentation” tab works for both models and blocks, letting you pick a Title preview field and an Image preview.
And second, we introduced new field types that can be selected as title and/or preview fields:
Color fields show a handy swatch (with optional opacity);
Date/DateTime fields use a quick calendar icon and display the date itself;
Geolocation fields bring in a map preview;
Number fields can be used as title and show their integer or floating-point value.
How do I enable it?
Just head to the “Presentation” tab in your model or block settings to choose your Title and Image preview fields. No extra steps required!
See it in action 👇
Color, Geolocation, and Date fields will also provide a much cleaner interface when set as Preview Fields.
Why does it matter?
This update makes it faster and clearer to see what’s inside each record or block at a glance. If you’ve ever found yourself repeatedly opening blocks just to check their contents, you’ll love these new previews!
By default, all GraphQL queries on paginated items to our Content Delivery API return a response of 20 items.
While we'll still retain this as the default behaviour, we've increased the maximum number of items to 500.
You can manage this behaviour when making your queries using the first parameter like this:
{# Fetch the first 500 posts allPosts(first: 500) { id slug title description publishedAt content }}For more info on working with Pagination in DatoCMS check out the docs.
Handling complex user roles and permissions is complicated enough as it is, so we thought we'd try and simplify things on our end as much as possible!
Firstly, when creating highly specific and granular roles that are inherited from others, you'll see a cleaner and clearer indication of which permissions are inherited from parent roles.
While you're in the process of making any modifications or edits to them, we're also showing a new pill that explicitly highlights what's changing, so you can make sure everything's good before hitting save.
On the cosmetic side, we're also making it way easier to just understand the roles you're working with. Inside Content Permissions, all the rules are now shown as actual readable sentences instead of "disabled form fields" which are just so much more readable!
As one of the most used and installed plugins in the DatoCMS Marketplace, this update was long overdue.
You can now update this plugin to V1.0.24 which introduces custom breakpoints for desktop, mobile, and tablet, allowing your editors to preview Draft and Published content within the CMS for each device.
Install the plugin via the Marketplace. If you already have it installed, you can head on to Configurations > Plugins and click to Update the plugin to the latest version.
A new enhancement has just been released that should allow for easier investigation of any issues encountered with the indexing of pages by our Site Search functionality.
By opening the details of events labeled "Site spidering completed with success", it is now possible to access a detailed log of the operations performed by our crawler, including analysis of the robots.txt and any sitemaps.
At the end of the log, you will also find a handy list of pages that encountered indexing problems.
Another one for content best practices! We're rolling out an option to stop CMS users from publishing invalid records.
How can published records be invalid you ask? Imagine records where title fields were required, and everything was published correctly. No sweat. You now extend that model to add in a new subtitle field which is also required. At this point, all the records in that model will require you to update them by filling in the subtitle field before their next publish.
While we'll enable this flag to TRUE for all new projects, you can easily enable it in your existing project under Configuration > Available Updates.
We’ve made a small but significant change to the way new models are created.
To enforce editorial best practices and provide better flexibility for your content workflows, draft mode will now be enabled for all new projects. While this is the new default, you are able to override this when creating new models, under the model's validation settings.
Additionally, for existing projects, we’ve added an option to enable this setting. You can find it in Configuration > Available Updates.