Migrate from Evam to Salesforce Sales Cloud

Evam Customers map to Salesforce Contact as the primary record, with an Account created from the Customer's organization or company field where present. We apply a 1:N split logic: if the Evam Customer record contains an associated company domain or explicit organization field, we create a parent Account and attach the Contact via AccountId. Customers without an organization association map directly to a Contact with no AccountId (a personal contact). We preserve all standard profile fields (name, email, phone, demographic attributes) and flag every custom Customer property for field-level mapping against Salesforce's typed field model.

Evam Events (behavioral and transactional touchpoints) map to Salesforce Task and Event based on event type classification. Behavioral events with a duration (e.g., session duration, interaction time) map to Event records with StartDateTime and EndDateTime preserved. Discrete transactional events (clicks, form submissions, status changes) map to Task records with ActivityDate set to the original Evam event timestamp. We scope the event export to a defined time window (typically 90-180 days) to stay within API quotas and produce a validatable dataset. Older event data is aggregated or sampled and documented for reference rather than fully migrated.

Evam Journeys are the core orchestration unit: sequences of steps, conditions, wait timers, and channel actions tied to customer segments. Journey definitions are not exposed via a documented export endpoint. We perform API snapshots and manual documentation during discovery to capture journey topology (step sequence, branch conditions, entry/exit rules, channel assignments). The migration output includes a written journey inventory with a recommended Salesforce Flow or Campaign member logic rebuild for each active journey. We do not migrate journey logic as executable code.

Evam Campaigns attached to journey steps or run independently map to Salesforce Campaign. Campaign metadata (name, status, start date, end date, budgeted cost, channel assignments) migrates directly. Campaign performance metrics (open rates, click rates, conversion rates) are derived metrics computed in Evam's reporting layer and do not have a source-data equivalent to migrate; we document these as reporting baselines for the customer to rebuild in Salesforce Reports post-migration.

Evam Segments are customer groupings used to filter journey entry and campaign targeting. Segment definitions export as rule sets or filter configurations. We preserve the membership criteria in a written segment inventory so that segments can be rebuilt as Salesforce static Campaigns (member list-based) or dynamic Campaigns (filter-based using Salesforce Reports or Flow criteria). The original Evam segment membership snapshot migrates as a static Campaign Member list for immediate use.

Evam Channels (SMS, push notifications, in-app, pop-up) are registered application environments with sender IDs, push credentials, and notification configurations bound to Evam's environment. These credentials cannot be moved. We document the full channel configuration during discovery (sender ID format, API keys, registered app credentials, routing rules) and provide a re-setup checklist so the customer's operations team can re-register channel credentials in Salesforce (via MobilePush, Salesforce SMS partners, or Experience Cloud) before cutover.

Evam's AI-based propensity scores are computed per-customer within Evam's runtime environment and are not accessible via the documented API. We cannot migrate these scores directly. Customers relying on AI-driven routing in journeys should plan to re-run scoring in Salesforce Einstein 1 AI post-migration, which requires a separate Einstein 1 Sales Cloud or Data Cloud activation. The migration delivers a customer-level score history export in CSV format for reference and manual upload if the destination supports custom scoring fields.

Extended properties on Evam Customers defined beyond the standard schema migrate to Salesforce custom fields on Contact (for customer-person attributes) or Account (for customer-organization attributes). We perform field-by-field mapping during scoping, noting Salesforce data type compatibility (text, number, date, picklist, checkbox, formula). Custom fields on Evam Customers without a clear Salesforce analog are flagged for explicit customer decision during mapping review.

Extended properties on Evam Events migrate to Salesforce custom fields on the corresponding Task or Event record based on event type classification. We map the Evam event property schema to Salesforce field types, preserving payload data where Salesforce's custom field model supports the format. Large or unstructured event payloads (JSON blobs, nested objects) are documented rather than fully migrated and are flagged for re-ingestion via Salesforce Event Monitoring or a data warehouse integration post-migration.

Evam engagement records (calls, emails, meetings logged against Customers or within Journeys) map to Salesforce Task with TaskSubtype, Event with start/end times, or EmailMessage records linked to Tasks. Engagement timestamps migrate as ActivityDate on Task and StartDateTime/EndDateTime on Event. The WhoId on migrated engagement records points to the converted Contact; the WhatId points to the related Account, Opportunity, or Campaign. We use the Salesforce Bulk API 2.0 with chunking and parent-record resolution to handle engagement volumes that exceed CSV loader capacity.

Notes attached to Evam Customers or recorded within Journeys map to Salesforce Note records linked via ContentDocumentLink to the parent Contact, Account, or Campaign. Note body migrates as rich text with image attachments preserved as separate ContentDocument records. We resolve the parent record reference at migration time using the Contact or Account ID from the Customer mapping.

Evam Owners (users who created or are assigned to Customers, Events, Campaigns, and Journeys) map to Salesforce User records by email match. We extract every distinct Owner referenced across migrating objects and match against the Salesforce destination org's User table. Any Evam Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Active/inactive status on the Salesforce User must be confirmed by the customer's admin to ensure the OwnerId reference is valid.