Migrate from Iterable to Microsoft Dynamics 365 Sales

Iterable User Profiles have no single Dynamics CRM equivalent. We split at migration time using the Iterable Lifecycle Stage property: profiles with Stage = subscriber, lead, or MQL map to Salesforce Lead; profiles with Stage = SQL, customer, or evangelist map to Salesforce Contact attached to an Account. The original Lifecycle Stage value preserves in a custom field hs_original_lifecycle__c on both Lead and Contact. Email address is the dedupe key. Phone, address, and any custom profile fields typed accordingly on the destination object.

Iterable does not have a native Company object but List membership associates profiles with named organizations. We extract these organization names from List membership records and create Account records in Dynamics. Domain extraction from profile email addresses supplements the Account name when organization attribution is ambiguous. Accounts are inserted before any Contact or Lead import so that the AccountId lookup resolves at record creation.

Iterable Lists are collections of user profiles used for audience segmentation. We create a Dynamics Campaign for each Iterable List and populate CampaignMember records by resolving the Iterable user profile IDs to the corresponding Lead or Contact IDs created during the profile migration. The Iterable List name and description map to Campaign name and Description. Active/inactive List status does not have a direct Dynamics analog, so we capture it in a custom Campaign field list_status__c.

Iterable Custom Events track behavioral data beyond profile updates. Each event has a name, userId reference, and arbitrary metadata payload. We migrate Custom Event history as Task records with a custom Task record type (e.g., IterableEvent) and custom fields for event_name__c, event_payload__c (JSON blob), and original_timestamp__c. WhoId on the Task resolves to the migrated Lead or Contact by the original Iterable userId. We flag events with payload structures that cannot be flattened into Dynamics field types for case-by-case resolution during scoping.

Iterable Campaigns (the sendable units with channel, template, and schedule configuration) map to Dynamics 365 Campaign. We export campaign name, channel type, status, start and end dates, and sending schedule as Campaign metadata. Campaign-level metrics (send count, open rate, click rate) from Iterable export as custom numeric fields on the Dynamics Campaign. Note that template content and Journey associations do not migrate as code; we document them separately.

Iterable Journeys are multi-step, multi-channel automation workflows with branching logic and AI decisioning nodes. Microsoft Dynamics 365 Sales has no equivalent Journey builder. We do not migrate Journey definitions as code. We export Journey metadata including name, trigger conditions, step count, channel per step, branching rules, and Catalog item references into a structured JSON inventory document. The customer's admin uses this document to rebuild the equivalent logic in Sales Sequences (available with Sales Engagement license) or Power Automate flows. Journey re-trigger behavior is explicitly called out because Dynamics Sequences are cadence-based, not event-triggered.

Iterable Templates define message content with HTML and Handlebars personalization syntax. We export template name, channel type, subject line, and content structure as a written template inventory. Dynamic Handlebars expressions are documented with their field reference equivalents for translation to Dynamics email template tokens. Template content does not migrate as deployable code; the admin rebuilds in Dynamics Email Templates or Power Automate approval flows.

Iterable Catalog stores product data for dynamic content insertion in messages. We export Catalog schemas and item records to migrate as Dynamics Product2 records. The Iterable Catalog item ID maps to a custom Product2 field catalog_id__c for cross-reference. If the customer uses Dynamics Business Central as an ERP, we coordinate the Product2 sync strategy with the ERP's item schema to avoid duplication. Catalog-to-Journey step associations do not migrate; these are documented in the Journey rebuild inventory.

Iterable Purchase events record transaction data (orderId, total, items, userId). We map Purchase events to Dynamics Opportunities with the Iterable orderId stored in a custom Opportunity field purchase_order_id__c, total amount as Amount, and item details in OpportunityLineItems resolved from the Product2 catalog mapping. Closed-Won Opportunities with a purchase event source are flagged with a custom Opportunity field purchase_event_source__c = true.

Iterable tracks channel-level opt-in/opt-out status per user for email, SMS, push, and in-app. We migrate these to Dynamics Contact fields: EmailOptOut for email, and custom fields sms_opt_out__c, push_opt_out__c, and inapp_opt_out__c for the respective channels. Subscription event history (timestamp of opt-in and opt-out events) migrates as Task records with the IterableEvent record type to preserve the compliance audit trail.