Promote only what you route on
Promote a field on its message type when, and only when, a subscription filters on it, a router branches on it, an adapter parameter binds it, or an operator needs it for tracking. Everything else stays in the message body. A wide promoted context is cost without benefit.
Promotions are the routing and visibility surface of a message: named expressions defined on the message type, surfaced as {{Promoted.MessageType.Name}}, the small set of values the bus and the operator reason about. It is tempting to promote “just in case,” but every promotion is another expression to evaluate, maintain and reason about. Dozens of speculative promotions make filters harder to read and bury the two or three fields that actually drive routing.
Promote with a reason. If you cannot name the subscription, router, adapter binding or tracking view that consumes a value, leave it in the body where it already lives, it is still there if a real need appears later. Adapter bindings count because adapter parameters are plain strings: they substitute {{…}} tokens but never evaluate a body path, so a payload value an adapter needs must arrive promoted or in a Variable. This keeps the context lean and the routing logic legible, for operators and for the AI Accelerator alike.
One constraint sits underneath all of it: only XML and JSON message types support promotions. A type carrying a raw format, an EDI interchange or an HL7 feed for instance, has no promoted surface at all, so if you need to route on something inside it, disassemble it to XML or JSON in the pipeline first and promote on the type that comes out. See Message types for the format list and what each one does.