Export & import

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.

4 min readUpdated Sep 18, 2026EmailRequired settingsValidation
Quick answer
In shortHandle Nintex Exchange message wrappers, ReplyTo, unresolved user/group identities, and untyped recipient collections without dropping recipients.
Most likely causeThe 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.
What to do nextMake the fix, generate a new package, and import the new ZIP instead of retrying the old one.

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.

Variable-backed SharePoint group sites

Group-member lookups retain their original site variable expression rather than substituting a default destination. A runtime HTTPS URL check precedes the lookup; its checked value becomes the connector dataset. Missing or invalid sites still fail. Required connections, permissions and actual group membership must be verified in the destination tenant.

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.

Related articles

Keep reading the next most relevant guides for this workflow pattern.