Publishing record and keep references to unpublished records


while we really enjoy working with dato (currently the 2nd customer project) we’re now confronted with the requirement to publish records whilst keeping referenced unpublished records - e.g. when working with scheduled publishing. A quick search revealed this post from @naren.bellala in the support forum. Will this be possible anytime soon?


hello @tools, the problem with your request is that it would mean saving a “broken” state, where the published record has links that are not visible on the API side. In general, draft/published state, like validations, are always enforced on record saving, to avoid leaving broken or unclear states.

What you could do is have a published record where you add links to draft records. Then you save again the main record, which is going to be in a “updated” state. The published endpoint is going to return the latest published version without links, while you retain links to draft records in the draft endpoint. Then when you are ready you can publish the main record and all its linked records publishing the main one (as mentioned in the linked topic).

Hope this clarifies? I don’t think we are going to change this behaviour though.

We also have this exact problem. We’re using a system with links to records as a way to be able to have translated content separated from the main record to be able to work with each translation separately (ex we have a landing-page for a site where we have published English and Spanish translations as a linked record to the landing-page, but Swedish and German records are WIP drafts and a Polish translation are planned to be publish the next day due to some confidential information not allowed to be published before 12:00 the next day). This setup with a parent record that holds references to all translated contents that each are it’s own record works good except for that we can’t link to a record when it’s a draft. Preventing us from doing things like schedule a translation.

Currently we can make a workaround where the editor needs to create and publish a new translation for each locale when they create a new page, and then there’s a check-mark that says that this translation is a draft. After it’s published, the editor can start working with the translation for real and using the draft function.

We have a suggestion how it could maybe be solved without interfering with all DatoCMS customers (as an opt-in behaviour).

When using a record link, there are some validation settings today where you can decide what should happen to linked records in different circumstances. Today it’s like this:

When a publishing is requested and this field references some unpublished records:

  • Fail the operation and notify the user
  • Publish also the referenced records

So there it could also be an option like this:

  • Return null/do nothing, the referenced record will keeps it’s current draft state

If this behaviour is chosen, GraphQL will return a null value while trying to fetch the content. Or some sort of 404 content with some meta that says this post is a draft and when it expect to be published if it’s scheduled. (Except if we’re in preview mode/using a preview token that includes also drafts in the response)

1 Like

Thank you very much @jonas.sandstedt for this!

Maybe we can consider this if the field is not required, otherwise it might cause problems. Otherwise the validation would pass but then graphql will return null. What do you think?

1 Like

That would work for our use case at least. We usually always does “null checks” in the client application anyway. But maybe is not a best practice to not return anything if it’s required.

But this would really improve the editor experience in our current (and future) project.

But understand it’s a bit complicated, as I guess you maybe need to update the record when the linked record has been published.

Yes, we’ll consider this for sure, cache invalidation is not trivial as the query doesn’t expose the draft record, so we don’t consider it, but then when it’s published, I guess you expect it to appear in the link, so we need to invalidate a query where the record doesn’t appear. But I see the potential of being useful, for sure.

1 Like

I understand the complexity. But I think the hassle to not being able to publish a record is bigger then needing to manually publish the changes when the linked records are published. Currently our editors needs to remove the non published record, remember where and to what record all references should be pointing, and then re-add them again manually when each record that is linked to it is published.

In some pages there is tens of links that need to manually be re-linked (and we have many hundreds of records). So then it would be easier to just make a manual note to republish that record when all those linked records are published.

I would say this is mostly a problem when building a new site/product, where a lot of records aren’t done and published yet, and maybe not a much of a problem when updating an already published record.

But if it’s an opt-in feature as suggested, this is maybe an okay solution that does not need to take caching into account?

(Should note we are using the linked record hack for translations, so each record always has around 10 linked records (one for each locale) that in itself contains a lot of linked records to other “parent” records)

1 Like

makes sense, we’ll surely consider this seriously, thank you very much for the detailed post

1 Like