A Service Bus queue receives Dataverse execution contexts from a registered service endpoint. The new consumer is a Node.js service that must read the context, including the target row's columns, without .NET assemblies. The current endpoint uses the default message format. What should the developer configure?
Select an answer to reveal the explanation.
Short Explanation
The default .NET binary format is like a letter written in a code only .NET can read. Flip the endpoint to JSON and your Node.js service reads it like any other payload. Contracts decide how messages travel, not what language they're written in.
Full Explanation
A service endpoint can post the remote execution context in the default .NETBinary format, in XML, or in JSON. The binary format is intended for listeners that reference the Microsoft.Xrm.Sdk types; a non-.NET consumer should use JSON, which Microsoft added for cross-platform interoperability, so the Node.js service can parse the message body and read the input parameters, target columns and images directly. Generic binary converters do not understand the .NET data contract serialization used by the default format, so decoding would be fragile or impossible. XML is readable from Node.js, but calling the Dataverse Web API to rebuild rows adds round trips and permissions the requirement never asked for; the context already contains the data. Changing the contract from queue to REST changes how messages are delivered and requires an active listener endpoint, and it does not turn the payload into form data. Exam caveat: when the full HTTP payload exceeds the documented size limit, some context properties such as images and input parameters are removed, so consumers should check for the truncation indicator. Operational check: change the message format, update a test row, peek the next queue message and confirm the body is JSON containing the expected target columns.