Migrate from Devi to Salesforce Sales Cloud

Devi's primary object appears to be a social-sourced prospect record, inferred as a Lead equivalent from G2 mentions of 'high-intent lead detection.' We map whatever primary contact or lead object Devi exports to Salesforce Lead. Required Salesforce Lead fields (FirstName, LastName, Email, Company, LeadStatus) are sourced from Devi's corresponding contact properties. We flag any Devi records with missing required fields for customer review before insertion because Salesforce rejects records missing LastName and Company on Lead.

We create custom fields on Salesforce Lead to capture Devi's intent-signal properties (social platform source, engagement score, content type that triggered detection). These custom fields (devi_signal_source__c, devi_intent_score__c, devi_trigger_content__c) are created during the schema design phase and receive data through the CSV or API extract. The fields are type-mapped to Salesforce Number (for scores) and Picklist (for source platform names) to avoid text-field reporting limitations.

Devi's research corpus contains no evidence of an Account or Company object, but any company-level data from the export (domain, industry, size) maps to Salesforce Account. If Devi's export contains only individual contact records without a parent company field, we create a synthetic Account using the contact's domain or company name for each unique value. This ensures Contacts can be linked to Accounts at insert time rather than being orphaned.

G2 reviewers cite AI-generated visual content as a valued Devi feature. If Devi's export includes media files or URLs to hosted content, we migrate them as Salesforce ContentVersion records linked to the parent Lead or Account via ContentDocumentLink. We preserve original file type, creation date, and any Dev-provided metadata as ContentVersion custom fields. Binary file ingestion uses the Salesforce ContentWorkspace API; URL-only exports are stored as a custom Text field pointing to the archived content location.

Devi's user management and seat model are unverified. We resolve Devi's record owners by email against the destination Salesforce org's User table. Any Devi owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import. We do not create Salesforce Users as part of the migration; only OwnerId references are resolved against existing Users.

If Devi's data model includes call engagement records (implied by a social-selling tool that tracks prospect interactions), they migrate to Salesforce Task with TaskSubtype = Call. Call duration, disposition, and recording links map to custom Task fields. WhoId on Task resolves to the migrated Lead; ActivityDate preserves the original timestamp for timeline ordering.

Any email engagement records in Devi's export migrate to Salesforce EmailMessage (the content body) paired with a Task record (the timeline entry). WhoId on Task points to the migrated Lead; WhatId points to the related Account or Opportunity. EmailMessage Status (3 = Sent, 0 = New) is set from Devi's sent timestamp. We use Bulk API 2.0 for email batch inserts because EmailMessage requires a separate API call per record without Bulk support.

Meeting engagements from Devi's export map to Salesforce Event records with StartDateTime, EndDateTime, Subject, and Location preserved. EventRelation records are created for each attendee, linking to the migrated Lead or Contact. We validate that the EventRelation references resolve to existing Salesforce records before insertion.

Devi notes and annotations attached to lead or contact records migrate to Salesforce Note objects linked via ContentDocumentLink to the parent Lead or Account. Rich text formatting is preserved as-is. If Devi stores note attachments as files, they migrate as ContentDocument records under the same ContentDocumentLink pattern.

If Devi's export reveals custom objects or record types beyond the inferred Lead and Content Asset, we pre-create equivalent Salesforce custom objects with __c API names matched to Devi's object names during the discovery phase. All custom fields are type-mapped to Salesforce field types, lookup relationships are established to standard objects, and custom object records are loaded last in the migration sequence because they frequently have foreign-key dependencies on standard objects that must be inserted first.

Devi's tag or label metadata (if exported as multi-checkbox properties) migrates to Salesforce multi-select picklist fields on Lead or Account. We define the picklist values during schema design based on the extracted distinct values to avoid a picklist of unknown values inserting invalid records.

If Devi's export includes pipeline stages or lead status values, they map to Salesforce Lead Status picklist values which we configure under Setup before migration. Each Devi's status label becomes a Lead Status value with an associated Converted checkbox state. The mapping preserves any custom scoring or stage labels as a custom field devi_original_stage__c for reporting continuity.