XSLT mapping Error: xsl:when cannot be a child of the xsl:element element.

It is always fun to return to one of my favorite topics: errors and warnings, causes and solutions, especially when working with XSLT mappings.

When you develop or maintain XSLT maps—very common in BizTalk Server, Azure Logic Apps, and Azure Integration Services—you may suddenly encounter the following error during compilation or runtime:

Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform mapD96A_INVOIC.
Error:Transformation failed.. —> System.Xml.Xsl.XslLoadException: ‘xsl:when’ cannot be a child of the ‘xsl:element’ element.
at System.Xml.Xsl.XslCompiledTransform.LoadInternal(Object stylesheet, XsltSettings settings, XmlResolver stylesheetResolver)
at Microsoft.XLANGs.BaseTypes.CompiledXsltWrapperTransform.Load(String xslt)
at Microsoft.XLANGs.BaseTypes.TransformBase.get_Transform2()
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, TransformMetaData trfMetaData, Stream[] inStreams)
— End of inner exception stack trace —
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, TransformMetaData trfMetaData, Stream[] inStreams)
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)

or

Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform mapD96A_INVOIC.
Error:Transformation failed.. —> System.Xml.Xsl.XslLoadException: ‘xsl:when’ cannot be a child of the ‘xsl:if’ element.

At first glance, this error may seem confusing, particularly when the XSLT appears syntactically correct. However, the root cause is usually simple and relates to an incorrect XSLT structure.

The good news is clear: this issue is not a product bug. Instead, it almost always comes from a misplaced conditional instruction in your XSLT.

Cause

To understand this error, we must remember one important XSLT rule:

• ✅ xsl:when can only exist inside xsl:choose.
• ❌ It cannot be directly nested inside xsl:element.
• ❌ It cannot be directly nested inside xsl:if.

A common incorrect pattern looks like this:

<xsl:element name="Status">
  <xsl:when test="Amount &gt; 0">
    <xsl:text>Approved</xsl:text>
  </xsl:when>
</xsl:element>

This structure is an invalid XSLT. The xsl:element instruction is used to dynamically create elements, but it cannot directly contain conditional instructions like xsl:when.

When the XSLT processor encounters this, it throws an error complaining that xsl:when is not allowed as a child of xsl:element.

Solution

The fix is straightforward: wrap your conditional logic inside an xsl:choose block and place it inside the xsl:element.

The correct and valid XSLT example:

<xsl:element name="Status">
  <xsl:choose>
    <xsl:when test="Amount &gt; 0">
      <xsl:text>Approved</xsl:text>
    </xsl:when>
    <xsl:otherwise>
      <xsl:text>Rejected</xsl:text>
    </xsl:otherwise>
  </xsl:choose>
</xsl:element>

This structure follows the XSLT specification:

• xsl:choose handles conditional logic
• xsl:when and xsl:otherwise define the conditions
• xsl:element only contains valid child instructions

Once corrected, the mapping will be executed without errors.

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son. 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira