Migrate from Synerise to Salesforce Sales Cloud

Synerise Profiles (the primary customer identity unit) map to Salesforce Contact. Default attributes — email, firstName, lastName — map directly. We preserve the Synerise profile UUID in a custom field synerise_profile_id__c for reconciliation. Custom profile attributes are audited during scoping; any that conflict with Salesforce reserved field names require renaming before migration. Profile tags migrate as multi-select picklist values on the Contact.

Synerise Profiles that represent unqualified prospects (those without a linked transaction event) can be mapped to Salesforce Lead in addition to Contact, depending on whether the customer uses Salesforce for marketing lead capture. We determine the split during scoping based on the customer's use of Salesforce Leads for new inbound prospects versus treating all Synerise Profiles as Contacts.

Synerise Events (page.visit, product.view, added-to-cart, transaction, and 40+ event types) do not have a direct Salesforce equivalent. We split Events into two categories: transactional events (transaction events with revenue data) become Salesforce Opportunities with custom fields; engagement events (views, clicks, opens, form submissions) become custom Engagement__c records linked to the Contact with event_type, event_timestamp, and custom properties as JSON in a long-text field. Event attribution resolves to the Contact via synerise_profile_id__c lookup during staging.

Synerise does not have a standalone Company object — company data lives as profile attributes or Brickworks schema records. We extract company-related fields from Profile attributes (company_name, website, industry, address) and map them to Salesforce Account fields. If company data lives in a Brickworks schema, we treat it as a custom object with a lookup to Account.

Synerise Transaction records (created via POST /v4/transactions or batch) contain line items, totals, and timestamps. We map to Salesforce Opportunity with the transaction total as Amount, transaction date as CloseDate, and line items as OpportunityLineItem via resolved Pricebook2. Order-level metadata (order_id, payment_method, shipping_method) becomes custom Opportunity fields.

Synerise Catalogs (product/item feeds used by AI recommendation models) map to Salesforce Product2 records with Standard Price Book entries. Item feeds exported from Synerise as CSV or JSON map to product records with the Synerise item ID preserved in a custom field synerise_item_id__c. Visual similarity configurations reference catalog images, which we export separately for Einstein retraining coordination.

Brickworks schemas (arbitrary record structures defined in Synerise's Data Modeling Hub) become Salesforce Custom Objects with __c API names matching the schema names. Field names, types, and constraints are documented in the migration manifest for manual recreation in Salesforce Setup. Lookup relationships between Brickworks records map to Salesforce lookup or master-detail fields on the corresponding custom objects. Schema definitions are not automated in migration; the customer's Salesforce admin recreates the schema first, then data loads follow.

Synerise Segments return true/false membership per Profile. Segment membership flags export as boolean values in the profile export. We map high-value segments to Campaign membership (if the customer uses Salesforce Campaigns for audience targeting) or to custom Contact fields with segment names as field labels. Complex segment rule logic (AND/OR conditions, time-decay, behavioral scoring) is not evaluated during migration — we document the rule definition for manual reconfiguration in Salesforce Flow or a segmentation tool.

Synerise custom profile attributes (any field beyond the defaults) map to Salesforce custom Contact fields. The critical constraint is that Synerise custom attribute names are immutable after creation — they cannot be renamed or deleted. We audit every custom attribute name during scoping and flag any that conflict with Salesforce reserved field names or naming conventions. If a conflict exists, the customer decides whether to create new Synerise attributes and run a data reconciliation or accept the naming mismatch in Salesforce.

Synerise workflows (defined in Automation Hub with trigger nodes, Profile Filter conditions, and action configurations for Send Email, Send SMS, webhook calls) are fire-and-forget by design — action completion does not gate workflow progression. This means in-flight workflows at migration cutover have no recoverable state. We export workflow definitions as JSON and deliver a written workflow inventory with trigger type, conditions, actions, and recommended Salesforce Flow equivalent. The customer's admin rebuilds workflows in Flow Builder post-migration. Active drip sequences and time-decayed offers will have gaps during the re-activation window.

Synerise AI recommendation configurations (personalized, visual similarity, last seen, top items, item comparison) are trained on catalog feeds and profile event history. We export recommendation model configurations (thresholds, item feed references, display rules) to the migration manifest. The underlying AI model — trained on Synerise's proprietary Cleora.ai embeddings — is not exportable. We flag that Salesforce Einstein or an external AI provider must retrain on migrated catalog images before recommendations resume. Visual similarity configurations are especially dependent on the image embedding model; only the configuration exports, not the model.

Synerise Campaign definitions (email, SMS, push, WhatsApp across 100+ Campaign API endpoints) map to Salesforce Campaign records. Campaign templates, audience rules, and scheduling migrate as configuration data in the manifest. Campaign assets (email templates, images, content blocks) do not migrate as files; we document the asset list for manual upload to Salesforce Content or Marketing Cloud Content Builder. Active campaign state (in-progress vs completed) is preserved in a custom Campaign field.

Profile tags in Synerise export as true/false boolean attributes per Profile. Tag names are free-form strings. We preserve the full tag set per Profile as comma-separated values in a custom Contact field Tags__c as a multi-select picklist. During scoping, the customer chooses whether tags map to multi-select picklist or to Salesforce Topics with TopicAssignment records, depending on their intended use for segmentation and reporting.

Synerise supports computed aggregates and expression results attached to Profiles (lifetime spend, purchase frequency, RFM scores). These export as scalar values. Since aggregates are computed from underlying events, destination recomputation depends on the migrated event history being complete and accessible in Salesforce. We map aggregate values to custom Contact fields and flag that formula fields in Salesforce can recalculate from Opportunity data post-migration if all transaction events migrated successfully.