The Rollout That Overwrote the French Hero
An AEM Sites MSM setup uses an English blueprint at /content/acme/global/en with live copies for French, German, and Japanese. Three rollout configurations exist: Standard Rollout triggered on activation, Promote manual, and Reset manual. French editors localize the hero component on 40 pages. German and Japanese inherit the hero unchanged. The next English blueprint activation overwrites the French hero on all 40 pages. The French pages are live copies, and the hero node has no inheritance cancellation. A legal footer component is also localized in French, but business owners want that footer to remain identical across all locales. There are two author instances and one publish.
1. Why were the French hero edits overwritten, and what would you inspect in the rollout configuration?
Read the worked answer
The French hero edits were made on an inherited live-copy node without cancelling inheritance. During rollout, MSM treats that node as still governed by the blueprint, so the Standard Rollout copies the blueprint hero over the French value. The fact that German and Japanese were unchanged is consistent: they had no local override to lose.
I would inspect the French live copy's relationship to the blueprint and the rollout configuration used on activation. Specifically:
- Which rollout configuration is attached to the French live copy and which trigger fired.
- Whether the hero path is included in the rollout's content scope.
- Whether the hero node has any inheritance cancellation or detached relationship.
- Whether the French edits were made before or after the last rollout.
The key distinction is between a local edit that is allowed to persist and a local edit on an inherited node that will be overwritten. The overwrite is expected behavior for inherited content; it is not a replication failure.
2. How would you handle the hero and the legal footer differently? Give the operating model, not just the property to change.
Read the worked answer
The hero is locale-specific content, so French should own it. I would cancel inheritance for the hero component on the French pages, or detach those pages if the whole page should become independent. After that, French edits survive rollouts, but French no longer receives blueprint hero updates. That tradeoff must be accepted explicitly by the business; if the blueprint must still push structural changes, I would cancel inheritance only on the hero component, not the whole page.
The legal footer is the opposite: it should remain globally consistent. French should not localize it independently. The footer should stay inherited, and changes should be made once in the English blueprint and rolled out. If French already has a local footer override, I would reconcile it back to the blueprint before relying on rollout.
The operating model is a content-ownership decision per component: global components stay inherited; locale-specific components are explicitly detached or inheritance-cancelled. Applying one rule to the whole page would either lose French localization or prevent global legal updates.
3. What would you verify before changing rollout behavior, given that there are two author instances and one publish?
Read the worked answer
Before changing rollout configuration, I would verify which author instance is authoritative for the French edits and whether both authors see the same live-copy state. With two author instances, a change made while replication or activation is delayed can make the live copy appear inconsistent. I would confirm that the French hero edits are replicated and visible on both authors before drawing conclusions.
Then I would test on a single French page: cancel inheritance on the hero, activate the blueprint, and confirm that the local hero survives while the footer still updates. Only after that would I apply the change to the remaining 39 pages. I would also check the publish rendering anonymously, because live-copy status is an authoring concern but the published page must still show the correct locale content.
Finally, I would document the rollout trigger. If Standard Rollout runs on activation, every blueprint activation becomes a potential overwrite event. The team needs to know which components are locally owned before the next activation, not after.