As a direct message creator, the receive adaptor has a practically unfathomable power over the message context. It kindly writes to the context whatever it is that an adaptor designer's infinite power contemplates: the properties it considered to be useful and valuable, but two of these properties are extremely important.
These are "MessageType" and "InboundTransportType". They so important not only because most of subscriptions are evaluated on the "MessageType" stuff, but also because sometimes promoted properties are only the one way to link together the content and the context of the message.
The story of promotion, began in the receiver, is unfinished business. If following the BizTalk Engine and the XML Pipeline (if desired), within which XML Disassmbler component pushes up all the message fields and attributes marked as promoted, into the same message context. You can rely on this feature for safely map the inbound document into another one as the part of receive port. If the target of mapping does not have the same structure as the original message and you wondering how to pass into the 'extended' fields - just promote them in the original message and XML Disassambler will do the job. 'Extended' fields will be passed into in the message context.
Following the message life-circle, the context is brought to the orchestration.
 Here the things going easy: despite any transformation, you can pass through the context as simple as coping it all (Message2(*) = Mesage1(*)) or its part (Message2(MyPromotedPropert1) = Message1(MyPromotedProperty1) ) to the transformation target. But how the orchestration itself can promote additional properties?
Well, it actually does so a lot when it uses correlation sets, dynamic port addressing and so forth. All it is about the promotion. For example, when XLANG/s schedule assigns the dynamic port address; it actually asks the engine to stick the address property on the outbound message so the further processing will takes it into the consideration. The same is true about the correlations: the correlated properties are promoted when leaving the schedule on behalf of their 'initialization' and are participated in subscription evaluation when they come back in the 'following' receive.
Explicit intentions to promote the property also may be expressed by orchestration, but they remain just intentions.  Without passing to XML Disassembler these properties will never reach the context – so happens to the promotions did in the orchestration and passed through direct send port: no pipeline is attached to direct port processing and consequently no XML Disassembler will realize the intentions.
Going in opposite direction, there is must be a way to do the reverse operation that may be called as simple as context’s cleaning up. It’s generally good idea to keep the context as small as needed for the processing. (Maybe because the fact that if the context were only growing it would become Samoan.) Such operation is known as demotion and all its about is to populate the message content by the properties already published to its context. Usually after demotion, the context properties are cleaned up and sometimes just this part of the procedure is called demotion as well.
As you can deduce, the component responsible for this duty is XML Assembler build-in with a XML Send pipeline, although it is a bit quirky then its brother. Indeed, it rationally designed to ignore the message entries if they already were populated.  Given that sadness fact that xml-nills are considered to be the first class citizens in the document population, this rationality leaded to confuse many BizTalk-programmers. The special <empty> value presented in BizTalk mapper in 2006 edition dilutes the population.
Worth to note that property demotion may be based not only on the custom property schema you added to the BizTalk solution. When you build up the promotion for the document schema, you can reference any pre-build property schema that shipped with BizTalk.