Symptom
An XML report contains < and > where you expect visible < and > when the file is opened in a plain text editor.
Or HTML lines appear scattered across separate XML tags and text nodes.
Meanwhile a browser displays the content correctly, yet a downstream consumer insists the HTML is malformed.
Cause
An XML serializer must escape markup characters when HTML is stored as character data, so < and > in the serialized file are correct.
Any XML-aware parser resolves them back to < and > when reading the value.
Seeing entities in a text editor is not evidence of broken output.
The other half is real: if the HTML is imported line by line, the line boundaries and element structure are preserved as XML content instead of being emitted as one raw HTML document. That produces the "split into tags" symptom.
Fix
First decide what the consumer actually needs: XML character data that contains HTML, or a standalone HTML document.
For XML character data, keep the escaped representation and require the consumer to parse the XML before rendering the HTML. Do not strip entity escapes by hand; manual unescaping is how valid XML becomes invalid.
For a standalone HTML artifact in the classic engine, the technique is a second run: read the generated HTML file back as an input file, collect its lines into an array, join them into a single value, and map that value to the output field. Test the result for whitespace and line-break fidelity, and validate with both an XML parser and an HTML parser rather than eyeballing it in a text editor.
Use the two-pass pattern only for classic integrations
The two-pass read-back adds another operational dependency to the job chain. Current multichannel and HTML email capabilities generally provide a direct channel path that avoids serializing HTML through XML at all, so reach for this technique only when you are genuinely maintaining a classic environment.