In Sitecore XM Cloud, sharing a site across multiple headless tenants isn't supported out-of-the-box due to the isolated nature of tenants. However, there are a few alternatives depending on your specific requirements:

Key Points

1. SXA Shared Site:

   • SXA’s Shared Site feature allows sharing of presentation and data sources within a single tenant.
   • It does not support sharing across tenants by design, as tenants are meant to be isolated.

2. Restructuring the Tenant/Site Setup:

   • If sharing site content across brands is essential, consider restructuring your tenant and site setup to group related sites under a single tenant.
   • Example:
     • Tenant (Brand):
       • Site 1 (Microsoft)
       • Site 2 (Apple)

3. Item Cloning:

   • For specific content sharing, you can use the item cloning feature to replicate content across sites within a tenant.
   • This approach works well for small-scale content sharing.

4. Role-Based Access:

   • Within a single tenant, you can create shared folders/sites and assign specific roles to users for access control.

Proposed Structure Example

• Tenant A (Shared Site X):

  • Site 1
  • Site 2
  • Shared Site X

• Tenant B (Shared Sites X and Y):

  • Site 3
  • Site 4
  • Shared Site Y

• Tenant C (Shared Sites X, Y, and Z):

  • Site 5
  • Site 6
  • Shared Site Z

Recommendations

• If restructuring tenants isn’t feasible, use item cloning or shared folders within a single tenant.
• For better long-term scalability and fewer manual steps, align the tenant/site structure with the requirements for content sharing at the planning stage.
• If sharing is minimal, item cloning may suffice without extensive rework.

This approach should help address your team’s need for shared sites across brands while adhering to Sitecore XM Cloud’s design principles.

Sitecore XM Cloud: Custom Error Details in Content Editor (YSOD)

Sometimes, when using the Sitecore XM Cloud Content Editor, you might encounter the Yellow Screen of Death (YSOD). This raises a common question: Can we enable custom error details to see more information about these errors?

The answer lies in modifying the web.config file. In XM Cloud, while you can adjust settings using XDT transformations, Sitecore doesn’t provide a direct option to enable custom error details specifically for the Content Editor.

To make changes:

1. Check out the Sitecore documentation on XM Cloud build configuration.
2. Use XDT transformations to adjust the relevant settings in the web.config file for your instance.

This should allow you to customize error handling and potentially show more details during troubleshooting.

Step-by-Step Approach to Enabling Custom Error Details

1. Understand XM Cloud Deployment Model:
   Sitecore XM Cloud is a containerized environment, and configuration changes are handled through XDT transformations applied during the build process. You cannot directly edit the web.config in the deployed environment, but you can apply transformations during deployment.

2. Modify web.config Settings:
   To display detailed error information, update the web.config settings using an XDT transformation to include custom error configurations.

   Here’s an example of an XDT transformation snippet you can use:

   
   <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
     <system.web>
       <customErrors mode="Off" xdt:Transform="SetAttributes" xdt:Locator="Match(mode)" />
     </system.web>
     <system.webServer>
       <httpErrors errorMode="Detailed" xdt:Transform="SetAttributes" xdt:Locator="Match(errorMode)" />
     </system.webServer>
   </configuration>
   

   • customErrors mode="Off": Disables custom error pages and displays detailed ASP.NET errors.
   • httpErrors errorMode="Detailed": Configures the IIS server to display detailed error messages.

3. Apply XDT Transformations in Your Build Configuration:

   • Ensure the above transformation file (e.g., web.release.config) is included in your project.
   • During deployment, Sitecore XM Cloud will apply this transformation to the web.config.

4. Check Sitecore Documentation:
   Refer to the official Sitecore XM Cloud documentation on build configuration for guidelines on applying and validating XDT transformations in XM Cloud deployments.

5. Deploy and Test:

   • Deploy the updated configuration to your XM Cloud instance.
   • Trigger the error in the Content Editor to confirm that detailed error messages are now displayed.

Best Practices and Considerations

• Security Awareness:
  Only enable detailed error messages in non-production environments. Exposing detailed errors in a production environment can reveal sensitive information and pose security risks.

• Log Monitoring:
  Use Sitecore’s logging mechanisms and external monitoring tools (such as Application Insights) to collect and analyze error data without displaying it directly in the Content Editor.

• Rollback Strategy:
  Ensure you have a rollback plan in case the configuration changes cause unintended behavior.

Conclusion

While Sitecore XM Cloud does not offer a direct option to enable custom error details for the Content Editor, leveraging XDT transformations to modify the web.config file provides a powerful way to manage error handling. By applying these changes responsibly, you can streamline troubleshooting and improve the development experience.

For more detailed guidance, always refer to the official Sitecore documentation or reach out to Sitecore Support for assistance.