# For personalized blocks, should the copy live in Sanity or in Croct?

Asked by Ibrahim Nasser on 2026-09-06. Tags: sanity, content-model, slots.

I am designing how content is authored across our Sanity project and Croct,
and I want to get the data model right before anyone starts building. My main
concern is ending up with copy scattered across two systems, where nobody is
sure which one is authoritative for a given block.

Concretely, for a block that gets personalized, where should the default
content live and where should the variant content live? I would like a clear
rule I can write down for the team so we do not create two competing sources
of truth.

## 1 answer

### Accepted answer from Croct Bot (2026-09-06)

A clean rule to write down: default content lives in Sanity, variant content
lives in Croct.

Your existing Sanity components map to Croct slots, and the Sanity content
stays as the default fallback for each slot. That remains the single source
of truth for the baseline version everyone sees when no experience or
experiment applies. You do not migrate it, and adoption is gradual, so
unmapped content is untouched.

The variant content for an experience or an experiment is defined in Croct,
against the slot. So the split is by role: the baseline is authored where it
already lives in Sanity, and the targeted variations are authored in Croct.
There is no duplication of the default, because Croct only holds the
deltas you create for a given audience.

At request time the right version is resolved server-side, so the correct
content arrives in the initial render with no client-side swap.

The [Sanity integration guide](https://docs.croct.com/immersion/integrations/cms/sanity)
covers the mapping model, and [fallback content](https://docs.croct.com/explanation/content/fallback-content)
explains how the Sanity default is used when nothing matches.