Migrate from Ometria to Salesforce Sales Cloud

Ometria Contact records map to Salesforce Contact (for active customers and known buyers) or Salesforce Lead (for subscribers who have not transacted). We use the Ometria lifecycle stage and transaction history properties to determine the split: contacts with at least one order map to Contact attached to an Account; contacts with no orders and no account association map to Lead. The original Ometria lifecycle stage preserves in a custom field ometria_lifecycle_stage__c on both Lead and Contact for audit and reporting continuity.

Ometria Segments (dynamic rule-based groups) map to Salesforce Campaign with Campaign Members, or to a Salesforce Public Group used for sharing records. We export the segment definition rules and recreate them as Salesforce Campaign inclusion criteria or as a matching rule on a custom Segment__c object. Active segment memberships migrate as Campaign Member records so that historical segment membership is queryable at migration time. Segments that rely on Ometria-specific behavioral events that have no Salesforce equivalent are flagged for manual rebuild.

Ometria's dynamic customer attribute properties map to typed Salesforce custom fields on the Contact object (or on Account for company-level attributes). We apply Salesforce field-type mapping for each property: text strings become Text fields, dates become Date fields, numeric scores become Number fields, and boolean flags become Checkbox fields. Attributes that contain complex nested JSON or array structures that Salesforce cannot natively store are migrated as Long Text Area fields with a note in the field description to reconstruct from source data if needed.

Ometria Suppression Lists migrate to Salesforce's Block List feature (available in Sales Cloud and Marketing Cloud Account Engagement) to ensure GDPR and CAN-SPAM compliance continuity. We export the full suppression list, validate that every email address is present in the migrated Contact or Lead set, and upsert the addresses to the Block List object. Suppression rules (store-level or campaign-level) map to a custom Suppression_Rule__c object linked to Account or Campaign for future reference.

Ometria Order records map to Salesforce Opportunity representing the purchase event, with OpportunityLineItem records representing the individual SKUs purchased. The order_total and revenue fields migrate to Opportunity Amount and CloseDate. We note that Ometria's multi-touch revenue attribution model may report 15-20% different totals from Google Analytics; we validate against Ometria's native reports, not external analytics, and preserve the attribution model metadata as custom fields on the Opportunity for comparison at the destination.

Ometria Event records (order_placed, email_opened, page_viewed, custom behavioral events) map to Salesforce Task records for activity timeline continuity, or to a custom Event__c object if the customer's reporting requires the granular event schema that Ometria supports. Event property structures map to custom fields on the target object. Events with non-standard or freeform property schemas that cannot be typed into Salesforce fields are stored as JSON in a Long Text Area field with a note for BI tooling reconstruction.

Ometria Broadcast campaigns (one-time email sends) migrate as Salesforce Campaign records with the campaign name, send date, and audience segment preserved. Sending logs and delivery metrics (open rate, click rate, bounce) migrate as custom fields on the Campaign record. Individual email content does not auto-migrate as a Salesforce email template; we extract the HTML and deliver it in the handoff package for manual upload. Broadcast automation triggers and conditional branches do not migrate.

Ometria Lifecycle Programs (multi-step automation journeys) are documented as Salesforce Campaign records with step-by-step program structure preserved in the Campaign description. We export the full program tree including conditional branches, delay rules, and trigger events. The automation triggers, delays, and conditional logic cannot migrate to Salesforce Flow because the two automation models are architecturally incompatible. We deliver a written program inventory document that maps each Ometria Lifecycle Program to a recommended Salesforce Flow equivalent or Campaign Journey for the customer's admin to rebuild.

Ometria master template HTML is extracted directly and uploaded as Salesforce Classic Email Template or Lightning Experience Visualforce Email Template records. The Ometria account migration guide requires the HTML to be placed specifically in a master template slot; we follow that specification and verify rendering across desktop and mobile in a Salesforce Sandbox before production load. Dynamic content blocks and personalisation tokens are flagged for manual reconfiguration at the destination because they require destination-specific token syntax.

Ometria Store records (retail location data sources) map to Salesforce Account records with Account Type = Store and store-specific metadata fields (address, location type, regional code) migrated as custom fields. Store-level suppression rules migrate to a custom Store_Suppression__c object linked to the Account. For brands with fewer physical retail locations and primarily ecommerce operations, this mapping may be simplified or omitted based on scoping.

Ometria Subscriber records (contacts with explicit opt-in status) map to Salesforce Contact with HasOptedOutOfEmail and a custom ometria_consent_source__c field preserving the opt-in source and timestamp. Consent records are migration-critical for GDPR and CCPA compliance and must not be lost. We preserve subscription status, consent timestamp, and opt-in source, mapping each to the corresponding Salesforce field or custom field.

Ometria Visit data (onsite session behavior including page views and session duration) maps to Salesforce Task records with a custom Task Type = Visit and session duration stored in a custom field. Visit data reflects Ometria's own visit-counting logic which differs from Google Analytics attribution; we note this discrepancy in the migration reconciliation report and validate totals against Ometria's native reports. For brands where visit data is a core reporting metric, we recommend migrating to a custom Engagement__c object rather than Task to preserve the full session schema.

Ometria coupon pool configurations and promotion properties passed in order events migrate as custom fields on the Salesforce Opportunity (coupon_code__c, promotion_name__c, discount_amount__c). Coupon sync configuration that Ometria stores for automated coupon assignment requires replication via Salesforce Promotion or Campaign member logic, which we document in the handoff package. The customer's admin configures automated coupon assignment in Salesforce Flow or via an AppExchange promotion management tool.

Ometria Custom Data Exports (configured to AWS S3, Databricks, Google Cloud, Azure, or SFTP endpoints) that are not covered by the standard object mappings above migrate to Salesforce Custom Objects or Big Objects depending on volume. We use the Databricks or S3 export connector to extract the source data, transform it according to the field mapping, and upsert via the Salesforce Bulk API. Big Objects require separate metadata deployment before data load.