Migrate from Unim to Salesforce Sales Cloud

Unim Contact records map to Salesforce Contact for qualified buyer records. We resolve the split rule during scoping based on the customer's lifecycle or status custom field. The original Unim lifecycle status is preserved in a custom field unim_original_status__c on the Salesforce Contact for audit. If the customer uses Salesforce Lead for pre-qualified prospects, Contacts with a status below a defined threshold map to Lead instead. Schema discovery identifies which Unim Contact fields are standard versus custom so the mapping is complete before import.

Unim Company records map directly to Salesforce Account. We use the Company domain name as the dedupe key during import. The Account must be created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. Custom fields discovered on the Unim Company model map to custom Account fields (Account__c) pre-created in the destination org during schema deployment.

Unim Activity records carry timestamps, owner references, and optionally linked custom fields. We distinguish by activity type: call and task activities map to Salesforce Task with TaskSubtype=Call for call records; meeting activities map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Activity-to-contact linkage migrates as WhoId; activity-to-company linkage migrates as WhatId. Owner resolution uses email match against Salesforce Users. Historical timestamps are preserved by setting ActivityDate to the original Unim timestamp.

Unim note records map to Salesforce Note objects. Notes are linked via ContentDocumentLink to the parent record (Contact, Account, or custom object). Rich text formatting in Unim notes migrates as Salesforce rich text. If the customer used a bespoke Notes entity beyond the standard Activities model, we discover it during schema introspection and map it as an additional custom object.

Attachments in Unim are served via the Files dimension and require a separate API call per file to fetch the binary blob. We paginate file extraction to avoid overwhelming the Unim API and apply retry logic on 429 responses. Each file is uploaded to Salesforce as a ContentVersion record, then linked to the parent record (Contact, Account, or custom object) via ContentDocumentLink. Original filenames and MIME types are preserved. Large attachment volumes require Bulk API 2.0 for the Salesforce upload step.

We query the Unim custom-fields API endpoint to enumerate every active custom field on the Contact model, including its DataType ID (from the valuelists endpoint), ModelID, nullable flag, and display name. Each custom field is pre-created in Salesforce as a typed custom field before any Contact data is imported. DataType mapping converts Unim datatypes to their Salesforce equivalents (text to Text, integer to Number, date to Date, etc.). Nullable fields are created with the required flag disabled.

Same approach as Contact custom fields: we enumerate every active custom field on the Company model via the Unim custom-fields API, resolve DataType IDs from valuelists, and pre-create the corresponding Account custom fields in Salesforce before Account import. Company-specific custom fields that represent industry classification, tier, or regulatory flags are mapped with explicit picklist value alignment if Salesforce uses a restricted picklist.

Unim Activity records may carry custom fields that extend the standard activity schema. We discover these during schema introspection and pre-create matching custom fields on the Salesforce Task or Event object (depending on activity type) before activity import. Activity custom fields that store call disposition, meeting outcome, or task priority are mapped as picklist or number fields with value normalization applied during the transform phase.

Bespoke entity types beyond the standard Contact-Company-Activity triad are defined at the application level in Unim. We discover these via schema introspection of the entity definitions, enumerate their fields and relationships, and pre-create equivalent custom objects in Salesforce with __c API names. Multi-level lookup chains (custom object referencing Contact, referencing Company) are resolved at migration time by loading parent records first and using Salesforce external IDs as join keys. Any custom object without a clear Salesforce equivalent is flagged during scoping for the customer to decide whether to map it as a custom Salesforce object or a related list on an existing object.

Tag associations in Unim are stored as separate linked records or as array fields depending on the specific deployment. We preserve tag-to-record linkages as either Salesforce Topics with TopicAssignment records (for content-classification tags) or as multi-select picklist values on the target object (for record-level categorization). The customer chooses the tag strategy during scoping. Tags without a matching Salesforce equivalent are exported as a separate CSV for the customer's admin to apply post-migration.

Owner IDs assigned on Unim records are scoped to that specific Unim deployment and cannot be used as Salesforce OwnerId values directly. We map source owner IDs to destination User records using email or username as the join key. Any Unim owner without a corresponding Salesforce User is held in a reconciliation queue. The customer's Salesforce admin provisions missing Users before record import resumes. Inactive Salesforce Users can receive historical record assignments if the customer wants to preserve the owner attribution without reactivating the account.

Webhook configurations in Unim are environment-level settings that point to external system endpoints. These cannot be meaningfully re-imported into Salesforce's outbound messaging or Platform Event system. We document active webhooks during discovery and deliver a written inventory specifying each webhook's trigger, target URL, payload structure, and the equivalent Salesforce configuration (Outbound Messages, Platform Events, or an APEX callout trigger) that the customer's admin can implement post-migration.