Skip to main content

Understand Salesforce Data Model for Data Migrations

How to use Elements.cloud data model diagrams to plan accurate and reliable data load sequences during Salesforce migrations.

Updated yesterday

Why understanding data model is critical for data migrations?

During a data migration, failure to understand the Salesforce data model can lead to critical issues:

  • Improper load sequencing, causing parent-child data conflicts (e.g., loading Contacts before Accounts).

  • Broken relationships, where lookup or master-detail references are misaligned or missing, leading to orphaned data.

  • Transformation mismatches, where legacy data doesn’t fit the Salesforce schema due to incorrect field mapping or missing fields.

Without a clear understanding of the schema, teams risk data integrity problems, extensive rework, and missed go-live deadlines.


A comprehensive, visual understanding of the target data model ensures that migration scripts and tools are properly configured, reducing risk and accelerating delivery.

When to generate and analyze your Salesforce data model?

Use data model generation when:

  • You are scoping or planning a Salesforce data migration or consolidation project.

  • You need to validate existing schema before importing data into a sandbox or production Org.

  • You are assessing schema changes to accommodate data from legacy systems.

  • You are working with third-party migration tools and need to align on object structure and relationships.

Prerequisites

Before you start, make sure:

Data Model Generation is currently available in closed beta to the customers who have pre-registered for access.

We are planning GA release in May, subject to feedback from beta customers.

Plan migration using data model generation

Step 1: Understand the migration requirement

Before generating anything, clarify what data you plan to import and why. This shapes the scope of the diagram you’ll generate.

Example scenario: You want to import cases and issues from JIRA Service Management to Salesforce Service Cloud as you are moving from one vendor to another. In Jira, the key entities are epics, stories, bugs, and tasks. In Salesforce, these are often tracked via Case, Work Order, Task, but there is possibility of custom and managed objects of which you are unaware of.

Generalize your question to overall capability, like:

"How do we manage customer and internal work related to issue resolution?"

Step 2: Generate the schema diagram

Use the question / capability description from previous step as an input to generate your data model diagram.

Prompt example for the Jira–Salesforce use case:

“How do we manage customer and internal work related to issue resolution?"

This phrasing helps Elements select relevant objects like Case, Task, WorkOrder, and any custom ticketing structures like Bug__c or Epic__c.

Name the diagram accordingly (e.g. “Jira Integration Schema – April 2025”) and proceed to generate.

Step 2: Identify parent (root) objects

Start by spotting objects with many incoming flowlines—these are typically looked up to by other objects. Examples:

  • Accounts (referenced by Contacts, Opportunities, Cases)

  • Users (record ownership)

  • Products (for Orders, Opportunities)

These must be loaded first. They serve as the backbone of your data structure.

Step 3: Trace relationships downstream

Use flowlines to find which objects depend on your root objects:

  • Follow lines outward to identify children (e.g., Contacts → Opportunities → Tasks).

  • This reveals a hierarchy—each level depends on the one above it.

This tells you how to sequence your import:

  1. Load Accounts

  2. Then Contacts (linked to Accounts)

  3. Then Opportunities (linked to both)

  4. Then child objects like Tasks, Events, etc.

Step 4: Analyze junction and many-to-many objects

Look for objects that connect two others:

  • e.g., CampaignMember (joins Contacts and Campaigns)

  • OpportunityContactRole (joins Opportunities and Contacts)

These require both parent records to be loaded first. Sequence them last, and use external IDs or Salesforce record IDs to establish links.

Step 5: Validate relationship field usage

Hover over relationship lines to see field usage metrics:

  • If the field is always populated, the relationship is likely mandatory—ensure the related object is imported before this one.

  • If sparsely populated, the field may be optional—offering flexibility in sequencing.

This step helps optimize your migration scripts and handle edge cases where data might not cleanly align with Salesforce expectations.

Step 6: Identify schema gaps for transformation

If the data you wish to import doesn’t match any object in the diagram:

  • You may need to extend the schema (add custom fields or objects).

  • Or plan for data cleanup/transformation to align legacy formats with existing Salesforce definitions.

Did this answer your question?