Migrate from Real Properties to Salesforce Sales Cloud

Salesforce has no native property or listing object — every listing attribute requires a custom object

Real Properties stores listing records with built-in fields for bedrooms, bathrooms, square footage, lot size, year built, MLS number, and property type. Salesforce Sales Cloud ships with no real estate listing object — the Opportunity object holds transactional data (price, stage, close date) but none of the property-specification attributes. FlitStack creates a Property__c custom object with all property-specification fields as custom fields using the __c suffix convention. The Opportunity then holds the transactional data and links to Property__c via a lookup field. This separation means two records must be created, related, and validated per listing. Your Salesforce admin pre-approves the Property__c field list before migration runs.

Listing status to Opportunity Stage mapping requires a pick-list value table agreed before migration

Real Properties listing_status is a pick-list with values like Active, Pending, Under Contract, Sold, Off-market, and Withdrawn. Salesforce Opportunity StageName is also a pick-list, but its values are org-specific and tied to Sales Processes. A 1:1 mapping from Real Properties status to Salesforce StageName is required before any Opportunity can be created. FlitStack delivers a stage-mapping table during the planning phase: you confirm which Salesforce stage each Real Properties status routes to, whether probabilities need adjusting, and whether forecast categories change. If your Salesforce org uses record types keyed by property type, each record type may need its own stage pick-list subset — doubling validation work. Stage mapping must be locked before the migration commit.

Multi-owner listings create multiple Opportunity Contact Role entries — primary owner designation required

Real Properties allows N owner records to be linked to a single listing simultaneously — a common pattern for co-agency listings where a listing agent and a buyer's agent both appear on one transaction record. Salesforce OpportunityContactRole can store multiple contacts on an Opportunity, but one must be designated as IsPrimary = true. FlitStack sets the primary owner (by modification-date order in Real Properties, or your specified rule) as IsPrimary and adds remaining owners as non-primary roles. If your business logic assigns a different primary owner, that rule must be documented during discovery. Custom junction objects for co-owner roles beyond the standard buyer/agent pair are created as a separate migration deliverable.

Property photo URLs require download-and-re-upload, not direct URL reference

Real Properties stores property photos as hosted image URLs in a photo_gallery field. Salesforce does not display external URLs as native attachments on custom objects — files must exist in Salesforce's own ContentDocument/ContentVersion storage to appear in the Files related list on a Property__c record. FlitStack downloads each image from the source URL, processes it through Salesforce's ContentVersion API, and links it to the Property__c record. The 25MB per-file Salesforce limit applies; any image exceeding this is flagged before migration so your team can compress or selectively upload. Photo albums with hundreds of images increase migration time proportionally.

Unmatched owner emails block Opportunity creation — user resolution must complete before data load

Salesforce Opportunity records require an OwnerId referencing a live Salesforce User. FlitStack resolves Real Properties owner emails against active Salesforce User records. Any owner whose email has no matching Salesforce User is flagged in a pre-migration report. You have two options: create a Salesforce User for that person before migration runs, or assign their opportunities to a fallback owner. If you choose a fallback owner and later create the Salesforce User, manual re-assignment of OwnerId on migrated records is required. FlitStack will not commit any Opportunity without a resolved OwnerId — this prevents orphaned records with blank owners.