Preserve email recipients and resolve explicit identity requirements
Email fields are migration behavior, not optional cosmetic details. The converter retains supported To, Cc, Bcc, ReplyTo, subject, body, importance and From values. Missing mappings remain blocking rather than being replaced with a connection owner or an empty optional field.
Literal values and dynamic recipient references
The Exchange decoder reads supported literal/value wrappers, including designer data metadata, and retains direct variable references. HTML/Text body modes and Low/Normal/High importance are interpreted from their original values. The empty Nintex correlation header is treated as provider bookkeeping only when its exact supported name is present and its value is empty or omitted. Other custom headers, unknown content types and unsupported message fields still require an explicit mapping.
Unresolved identities require reviewed destinations
Under Required Settings, open Legacy source requirements → Source inputs, approval fields, and recipients. For each exact unresolved identity, enter the reviewed mailbox address or semicolon-separated list. The choice is tied to the source version, action and recipient field. A claims login or a group display name is not converted to an email address by guessing.
A verified group mailbox can preserve a mail-enabled group destination. Expanding a group into a fixed list is an explicit migration choice and does not preserve changing group membership. No automatic directory/group resolution is claimed by this setting.
Unknown collection item types
A declared string-array schema, or compatible source string-producing operations, allows the collection to be joined into a recipient list. An Array declaration by itself does not prove the item type. Unknown collections require an explicit email-string contract. The generated flow validates the original array and every item before sending, retains duplicate addresses, and rejects nulls, objects, numbers and missing values without coercion or filtering. The checked snapshots are consumed by the email step, and the final required To value must be nonempty.
Testing scope
Local package generation and validation do not establish live delivery or Power Platform import/runtime behavior. Parent/child acceptance is a separate local test lane with explicitly supplied source decisions. The general Desktop standard-export sweep alone does not certify that lane.

