Migrate from SellingLane CRM to Salesforce Sales Cloud

SellingLane Buyer records map to Salesforce Contact. Bidder ID, registration date, and verification status migrate as custom fields on Contact. Bidder tier or standing maps to a custom picklist field. Buyer email becomes Contact.Email (used as the dedupe key during import). Where the auction house manages business-level accounts (consignors, corporate buyers), we may also map some Buyers to Salesforce Account records and relate Contacts to those Accounts; the customer chooses the account strategy during scoping.

Some SellingLane Buyer records represent corporate entities (consignors, business buyers) rather than individual bidders. We identify these by domain-based email patterns or explicit business-type flags and map them to Salesforce Account records, creating related Contact records for the individual bidders within that entity. The customer decides during scoping whether to use a flat Contact model for all buyers or a Contact-under-Account model for business buyers.

SellingLane Lots map to Salesforce Product2 records. Lot number becomes Product2.ProductCode; item description becomes Name. Reserve price and starting bid migrate as custom numeric fields on Product2. Custom fields on lots (the schema is not publicly documented in SellingLane, so we discover field definitions during the audit phase via the platform's field configuration endpoint) map to custom fields on Product2. We cross-reference every custom field against live lot records during audit to confirm data completeness.

Bid records are the most migration-critical object because they are not standalone: each bid links a Buyer to a Lot and carries timestamp, amount, and bid type (floor, absentee, online). SellingLane does not expose bids as independent export records without Lot context. We export lots first, then export bids with the lot_id foreign key embedded, and reconstruct the relational stack in our staging schema before final import. In Salesforce, bids map to a custom Bid__c object (if the customer licenses custom objects) related to both the Contact (buyer) and Product2 (lot), or to Opportunity Line Items if the customer prefers a Deal-centric model. Bid type and timestamp preserve; bid ordering is validated against the original timestamp sequence.

SellingLane Auction Events group lots and bids by sale date, location, and catalog. Salesforce has no Auction Event object. During scoping, the customer chooses between two strategies: (1) reconstruct events as custom Auction_Event__c records with date, location, and catalog metadata, and relate lots (Product2) to the event via a lookup; or (2) store event metadata (sale_date, sale_location, catalog_name) as custom fields directly on the lot Product2 records, accepting that lots become independent. We flag this gap at scoping and document the chosen strategy before migration design begins.

SellingLane Registration records include buyer ID, event ID, registration date, and payment method on file. These map to Salesforce Task records linked to the Contact (if using Task) or to a custom Registration__c object related to Contact and the event record (if event reconstruction is chosen). Registration date and payment method on file migrate as typed fields. We validate that the related Contact record exists before inserting registration records to avoid orphaned registrations.

Post-sale payment records in SellingLane include amount, method, date, and buyer association. Where SellingLane tracks trust-account balances, we flag these for the customer's admin to decide whether to carry them forward as custom fields on Account or Contact (trust-account balance is not a standard Salesforce object). Payment amount and method map to custom fields on a Salesforce Opportunity representing the won lot, or to a custom Payment__c object related to Contact and Opportunity. We alert customers if any payment record references a buyer or lot that did not successfully migrate.

SellingLane uses auction-specific workflow stages (e.g., Registered, Won, Lost, Paid, Closed). These map to Salesforce Opportunity StageName values. We configure the stage values and their probability percentages in Salesforce before migration. Any stage with a custom automation trigger in SellingLane is flagged in the automation inventory we deliver to the customer. Stages that have no direct Salesforce equivalent (e.g., a 'Won-Invoiced-Paid' composite stage) split into separate Opportunity Stage and custom status fields.

SellingLane supports custom fields on auction listings, but the schema is not publicly documented. We discover custom field definitions during the audit phase by querying the platform's field configuration endpoint, generate a complete field manifest, and cross-reference every custom field against live lot records to confirm data completeness. We pre-create each custom field in Salesforce on Product2 with the appropriate Salesforce field type before migration. Custom fields with deprecated or deleted definitions in SellingLane can silently drop values; we flag these and confirm with the customer before final import.

Item photos, condition reports, and registration documents attach to Lots and Buyers in SellingLane. We export attachments via the platform's file storage and re-associate them in Salesforce using a naming convention that links each file to the corresponding Product2 (lot) or Contact (buyer) record. Files attach via Salesforce ContentDocumentLink. Large file volumes (>10,000 attachments) require chunked upload handling via the Salesforce REST API.

SellingLane auction staff assigned as lot owners or bidder managers map to Salesforce User records. We resolve owners by email match against the destination org's User table. Any SellingLane owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive SellingLane users map to Salesforce Users with IsActive = false unless the customer specifies otherwise.

Classification tags on lots and buyers in SellingLane export as a tag set per record. We apply these as Salesforce Labels on the corresponding Product2 or Contact record, or as a multi-select picklist field if the tag vocabulary is small and closed (fewer than 150 unique values). Tag-based automations in SellingLane do not transfer; we document each active tag trigger in the automation inventory for the customer's admin to rebuild in Salesforce Flow if needed.

Bidder verification status (approved, pending, suspended) is stored as a custom property on the Buyer record in SellingLane, not as a native enumerated field. During migration we map verification status to a custom picklist field on the Salesforce Contact record. We alert the customer if any buyer's verification status was set to a deprecated value no longer in the active picklist definition in SellingLane. The customer defines the picklist values in Salesforce during schema design.