Migrate from Bloomr to Salesforce Sales Cloud

Bloomr uses a single Contact object as the primary person record. Because Bloomr does not publicly document a prospect-versus-customer distinction, we apply a conservative Lead-first mapping strategy during scoping: all Contacts with no associated Deal are mapped to Salesforce Lead; all Contacts with at least one associated Deal are mapped to Salesforce Contact attached to an Account. We preserve the original Bloomr contact ID in a custom field bloomr_contact_id__c on both Lead and Contact for reconciliation. If the source API exposes a lifecycle stage, lead status, or contact type property, we apply that as a secondary split criterion.

Bloomr Companies map directly to Salesforce Account. The company name becomes Account Name; domain or website becomes the Website field; industry, size, and address fields map to their Salesforce equivalents. Account is created before any Contact import so that the AccountId Lookup relationship is satisfied at the moment of Contact insert. We use company name as the dedupe key during import to prevent duplicate Account creation.

Bloomr Deals map to Salesforce Opportunity. Deal name becomes Opportunity Name; deal value maps to Amount; expected close date maps to CloseDate; stage name maps to StageName. We configure a Salesforce Sales Process and Opportunity Record Type before migration so that stage picklist values are whitelisted. Closed-Lost and Closed-Won outcomes are preserved. OwnerId is resolved via the Bloomr-to-Salesforce User mapping.

Bloomr deal stages map to Salesforce Opportunity Stage values. If Bloomr uses a single default pipeline, we create one Salesforce Sales Process. If multiple pipelines are discovered during API profiling, we create one Record Type per pipeline and assign a corresponding Sales Process that whitelists only the relevant stage values for each business line.

Bloomr Users map to Salesforce User records. We resolve by email match during migration. Any Bloomr User without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Deals, Contacts, and Activities cannot be inserted without a resolved User record.

Bloomr call activities map to Salesforce Task with TaskSubtype set to Call. Call duration, disposition, and any notes migrate to custom Task fields. ActivityDate preserves the original timestamp. WhoId on Task points to the migrated Lead or Contact; WhatId points to the related Account or Opportunity. We use the Bulk API 2.0 for large call histories.

Bloomr email activities migrate to Salesforce EmailMessage records (the email body and headers) linked to an Activity Task record (the timeline entry). WhoId on EmailMessage points to the converted Lead or Contact; WhatId points to the related Opportunity or Account. We use the Bulk API 2.0 with chunking for email histories exceeding 50,000 records.

Bloomr meeting activities map to Salesforce Event. StartDateTime, EndDateTime, Subject, and Location migrate directly. Attendees map to EventRelation records pointing at the migrated Leads, Contacts, and Users. If the source API exposes attendee data, we create EventRelation records during migration; otherwise we note the attendee list in a custom Event field for manual follow-up.

Bloomr task activities map to Salesforce Task. Status, Priority, Subject, and ActivityDate preserve. Task assignment migrates by resolving the Bloomr owner reference to Salesforce OwnerId via the User mapping. Completed tasks retain their Status; open tasks are migrated as open to avoid triggering closed-task workflows in Salesforce.

Bloomr custom fields are discovered during live API profiling. We enumerate all custom field names, data types, and object associations before designing the destination Salesforce schema. Custom fields are created in Salesforce with type-mapped equivalents (text to Text, number to Number, date to Date, picklist to Picklist) before any data import. We preserve the original Bloomr field label in a field description for admin reference.

Attachment migration is conditional on API access. If the Bloomr API exposes file attachments linked to Contacts, Deals, or Activities, we migrate them to Salesforce ContentDocument via ContentVersion upload, linked via ContentDocumentLink to the parent record. If the API does not expose attachments, we document the attachment inventory in the UI during discovery and flag it as out of scope for the standard migration. Customers then export attachments manually from the Bloomr UI if needed.

Bloomr workflow rules, automation triggers, and sequence configurations are not accessible via documented export. We cannot migrate workflows as structured data. During discovery, we use a workflow audit template to capture every active automation from the Bloomr UI: trigger object, trigger condition, action type, and destination field or object. We deliver this as a written workflow inventory document with recommended Salesforce Flow equivalents for each automation. The customer's admin or a Salesforce partner rebuilds them post-migration.