Migrate from Omni.us to Salesforce Sales Cloud

Omni Scripts contain outreach sequence text, placeholders, and branching logic. Salesforce has no native Script object. We preserve the full script body as a Salesforce Note or a custom Scripts__c object (depending on whether the customer wants to rebuild sequences inside Sales Engagement or reference scripts manually). Script placeholders map to Salesforce Contact fields (FirstName, LastName, Email) and Account fields via a placeholder token map built during discovery.

Omni Target Accounts (company-level records with name, domain, and firmographic data) map directly to Salesforce Account. Company name maps to Account.Name; domain maps to Account.Website; industry, employee count, and revenue from Omni custom workbook fields map to equivalent Salesforce standard or custom fields. Account is the parent record for all Contact imports and must be written first.

Omni Responses are reply records tied to a Script and a Target Account but contain no standalone contact data. We reconstruct the Contact layer by extracting respondent email, name, and phone from the Response payload and linking it to the associated Account. Each Response becomes a Task (with subject, body, and timestamp) linked to the reconstructed Contact and Account. Responses that contain no contact data become Tasks attached to the Account only.

Omni Case Studies are content attachments linked to accounts or scripts. Salesforce has no native Case Study object. We export the text content and metadata and map it to Salesforce Note records attached via ContentDocumentLink to the relevant Account or Contact. If the customer wants a dedicated Case Study record type, we create a custom CaseStudy__c object during schema design.

Omni Automatic Pausing rules govern when outreach sequences pause based on prospect actions (reply, bounce, meeting booked). These are logic rules, not data records. We document each active pausing rule as a written specification with its trigger condition and action, then recommend the equivalent Salesforce Flow record-triggered automation (such as a Decision element checking EmailMessage status or Event creation). The admin rebuilds inside Flow; we do not migrate workflow logic as code.

Omni workbook custom fields (schema, shared, and workbook layers) are discovered via the model IDE before migration. We enumerate all active custom fields and their types, then map each to a Salesforce standard field (if one matches) or a custom field (__c) on the appropriate object. Duration fields and calculated fields require transformation logic during import. A pre-migration field audit is run against the Omni model to enumerate the full custom field inventory.

Omni user records map to Salesforce User records by email match. Role and permission structures in Omni are minimal, so we create baseline User records without granular access control preservation. The customer's Salesforce admin provisions the matching User records before migration begins, or we use the Salesforce API to create Users with the System Administrator profile as a baseline.

Omni Target Accounts store a company domain field. We map this to Account.Website (with https:// prepended if absent) and also create a custom Text field omni_domain__c on Account to preserve the raw domain for deduplication against other account sources.

Omni Scripts use placeholders (such as {{first_name}} or {{company}}) that reference contact and account fields. During migration, we build a token map that links each unique placeholder token to a Salesforce Contact or Account field. When the customer rebuilds sequences in Salesforce Sales Engagement or a custom Flow, they reference this token map to wire the correct field merge.

Omni Response records include a timestamp for when the response was recorded. We map this to Task.ActivityDate to preserve the activity timeline ordering inside Salesforce. Responses without a timestamp are assigned the import date as ActivityDate and flagged in the reconciliation report.

Omni Scripts support conditional branching (different text paths based on prospect actions). Salesforce has no native script-branching model. We document the branching logic as a written decision tree and deliver a Flow diagram recommendation so the customer's admin can rebuild the branching sequence as a Salesforce Flow with Decision elements or inside Sales Engagement sequences. This is a documentation deliverable, not a code migration.

Omni Target Accounts may belong to multiple account lists (segments). Salesforce Campaign does not naturally model B2B account lists, but it can serve as the target for Account-based marketing motions. We map list membership to Campaign with AccountIds on CampaignMember, or to a custom AccountList__c junction object if the customer needs many-to-many account-list relationships. The customer chooses during scoping.

Omni.us does not expose a native Activities object in its API. Call logs, email opens, and meeting records that exist only inside Omni's internal sequence tracking are not accessible for export. We cannot migrate historical engagement data that Omni tracks internally but does not surface via API. We flag this gap in the pre-migration discovery report and recommend that the customer export any needed engagement history from Omni before the migration window begins.