Migrate from Omni.us to Microsoft Dynamics 365 Sales

Omni Target Accounts are the company-level records used instead of a traditional CRM Account object. We map these directly to Dynamics 365 Account records, preserving company name, domain, industry, and any workbook-level custom fields. The account_domain field maps to Account.Website. Target Accounts are imported before any reconstructed Contact records to satisfy the Account-Contact Lookup relationship in Dynamics.

Omni Responses tie a contact identifier (email, name, phone) to a Script and Target Account. Since Omni has no native Contacts object, we reconstruct the contact layer by grouping Responses by email address, creating one Dynamics Contact per unique address, and linking it to the Target Account (now Account) that the Response references. Any Response without an associated Script still generates a Contact record flagged for manual review post-migration.

Omni Scripts are outreach sequence templates with placeholders, branching logic, and step ordering. Dynamics 365 has no native Script object. We migrate script text and structure as a Note attached to the Account or as records in a custom Script entity (created in the destination Dynamics org during schema setup). Placeholder tokens and branching logic are preserved as structured text fields; the customer decides whether to use Notes or a custom entity based on rebuild intent.

Omni Case Studies are content attachments linked to accounts or scripts. Dynamics 365 has no native Case Study object. We export the text content, title, and metadata. Depending on the customer's preference, Case Studies migrate as Notes on the Account record or as documents in a SharePoint document library linked via the Dynamics-SharePoint integration. The choice is made during scoping and affects whether Case Studies appear in the Dynamics timeline or require separate navigation.

Omni Automatic Pausing rules govern when outreach sequences pause based on prospect actions. These do not migrate as active automation because Dynamics workflow models differ structurally. We export a written inventory of each Automatic Pausing rule with its trigger condition, pause action, and resume logic, mapped to a Power Automate Flow or Dynamics workflow design recommendation. The customer's admin implements the rebuild post-migration.

Omni's three-layer modeling (schema, shared, workbook) means custom fields exist at different abstraction levels and include Duration, calculated, and nested property types. We perform a pre-migration field audit against the Omni model IDE to enumerate all active custom fields and their data types, then map Duration fields to Dynamics Duration (integer in minutes), calculated fields to Dynamics computed column or plugin logic, and nested properties to JSON-encoded text or custom child entities. The customer approves the field map before any records write.

Omni user records map to Dynamics 365 User by email match. We extract every distinct user referenced on Script, Target Account, and Response records, resolve against the destination Dynamics org's User table, and flag any users without a matching Dynamics User for admin provisioning before the production migration begins. Role and permission structures in Omni are minimal so granular access control does not migrate; we create baseline User records with the Sales role.

Omni does not expose a dedicated Activities object in its API. We cannot migrate historical engagement activity records (logged calls, email opens, meeting completions) because the platform does not persist them as queryable objects. We surface this gap in the pre-migration data audit and note it in the reconciliation report. Any activity-style data in Omni (for example, response timestamps) migrates as metadata on the Contact or Script record rather than as a standalone Activity.