#Salesforce Sandbox Seeding with Production Data

This guide walks you through using iSyncSF to safely copy production data to a Salesforce sandbox for testing, development, or training purposes — with PII protection, automation control, and idempotent re-seeding built in.

#What is Sandbox Seeding?

Sandbox seeding is the process of populating a Salesforce sandbox with a representative subset of production data. Sandboxes start empty (except for Full Copy sandboxes) after a refresh, and testing with realistic data is essential for:

• Validating business logic and automation with real-world record volumes and relationships.
• Training users on actual data patterns without risking production data.
• Performance testing with datasets that match production scale.
• Reproducing production bugs that depend on specific data combinations.

#Why Use iSyncSF for Sandbox Seeding?

Compared to manual data loading or Salesforce Data Loader, iSyncSF provides:

• Automatic relationship handling. iSyncSF resolves parent-child relationships and remaps IDs automatically. You do not need to manually manage insert order or external ID mapping for lookups.
• Built-in PII masking. Sensitive data (emails, phone numbers, social security numbers) is anonymized before it reaches the sandbox, ensuring compliance with data protection policies.
• Automation control. Disable validation rules, triggers, flows, and workflows in the sandbox with a single click before seeding, and re-enable them afterward.
• Idempotent re-seeding. Using external IDs for upsert, you can re-run the same template after a sandbox refresh without creating duplicate records.
• Rollback. If the seeded data causes issues, roll it back from the Sync History tab to restore the sandbox to its pre-seeded state.
• Selective data. Use SOQL WHERE filters on template lines to seed only the data you need — for example, only Accounts from a specific region or Opportunities closed in the last year.

#Step-by-Step Sandbox Seeding Workflow

1. Connect to the sandbox via OAuth. Navigate to the Org Connection page. Click Connect and authenticate against the sandbox login URL (https://test.salesforce.com). Ensure the Connected App on the sandbox includes api, refresh_token, and offline_access scopes.
2. Create a sync template. Go to Template Management and create a new template. Select the sandbox Org Master as the target. Enable ContinueOnError so individual record failures do not abort the entire seeding job.
3. Add template lines for needed objects. Add a template line for each object you want to seed (Account, Contact, Opportunity, Case, etc.). Assign Sequence numbers so parent objects are processed before children (for example, Account = 1, Contact = 2, Opportunity = 3). Optionally add SOQL WHERE filters to limit the data (for example, WHERE BillingCountry = 'US').
4. Configure Object Settings with External IDs. For each object, open Object Settings and set a CustomExternalID field. This enables upsert behavior, making the seeding idempotent. If the object does not have a dedicated external ID field, consider using the Salesforce record ID as the external key.
5. Set up Data Masking for PII. Navigate to Data Masking and configure masking rules for sensitive fields: Email, Phone, FirstName, LastName, SSN, and any other PII fields. iSyncSF replaces real values with masked data before records are sent to the sandbox.
6. Disable automation in the sandbox. Go to Automation Control, scan the sandbox for active automations, then disable validation rules, triggers, flows, and workflow rules. This prevents automation from interfering with the bulk data load.
7. Run Preview/Scan. From the Preview/Scan tab, run a scan to validate record counts, check relationship resolution, and verify the data before committing. Review the results to confirm the expected records and objects are included.
8. Execute the sync. From the Execute tab, start the sync. Monitor progress on the Sync History tab. Check the DataSyncAuditLog for errors and the Application Logs for operational issues.
9. Re-enable automation. Return to Automation Control and re-enable all automations that were disabled in step 6.
10. Validate results. Spot-check records in the sandbox. Run reports to verify record counts match expectations. Confirm that relationships are intact (for example, Contacts are associated with the correct Accounts). Verify that masked PII fields contain anonymized values.

#Protecting PII with Data Masking

Sending production PII to a sandbox violates most data protection policies (GDPR, CCPA, HIPAA). iSyncSF's Data Masking feature ensures that sensitive data is anonymized before it leaves the production org:

• Field-level masking: Configure masking on individual fields. Each field can use a different masking strategy (random text, random email, random phone, etc.).
• Masking happens at the source: Data is masked before it is sent in the callout to the target org. The real data never reaches the sandbox.
• Consistent masking: The same source value produces the same masked value within a sync run, preserving data consistency for testing.
• Skip masking per relationship: You can exclude specific child relationships from masking using the SkipMasking option if those relationships do not contain PII.

Common fields to mask: Email, Phone, MobilePhone, FirstName, LastName, MailingStreet, BillingStreet, Description (if it contains customer notes), and any custom PII fields.

#Making Seeding Idempotent (External IDs for Re-runs)

Sandbox seeding should be repeatable. After a sandbox refresh, you want to re-run the same template without creating duplicate records. iSyncSF supports this through the CustomExternalID setting on Object Settings:

• When a CustomExternalID is configured, iSyncSF uses upsert instead of insert. If a record with the same external ID already exists in the target, it is updated. If no match is found, a new record is created.
• This means you can run the same seeding template multiple times — after each sandbox refresh — and the result is always a clean dataset without duplicates.
• For standard objects without a dedicated external ID field, you can create a custom field (for example, Source_Record_ID__c) and populate it with the Salesforce record ID from the source org. Configure this field as the CustomExternalID in iSyncSF.

#Disabling Automation Before Seeding

Sandbox automation can interfere with bulk data seeding in several ways:

• Validation rules may reject records that are valid in production but fail sandbox-specific conditions.
• Triggers may fire for every inserted record, causing CPU timeout errors or unwanted side effects (such as sending emails or creating tasks).
• Flows may create additional records or send notifications during bulk inserts.
• Workflow rules may update fields or trigger email alerts.

Use iSyncSF's Automation Control to disable these automations before seeding:

1. From the Automation Control tab, click Scan to discover all active automations in the sandbox.
2. Select the automations you want to disable (or select all).
3. Click Disable Selected.
4. After seeding completes, click Enable Selected to restore the automations.

Important: Always re-enable automations after seeding. Leaving automation disabled in a sandbox can mask bugs during testing.

#Resetting the Sandbox (Rollback)

If the seeded data causes issues or you want to start fresh:

1. Navigate to the Sync History tab.
2. Find the sync job for the seeding run.
3. Click Rollback.
4. iSyncSF deletes all records that were inserted into the sandbox during that sync job.

Rollback only removes records that were inserted (status code 7). Records that were updated (status code 2) are only restored if Data Versioning was enabled before the sync. To enable versioning, set the EnableVersion system property to true before running the seeding template. See the System Configuration Reference for details.

#Common Pitfalls

Forgetting to mask PII

Always configure Data Masking before the first sync run. Once unmasked PII reaches the sandbox, it is difficult to remove completely (it may exist in audit trails, email logs, or integration queues).

Wrong sequence order

If child objects (Contact, Opportunity) have lower Sequence numbers than their parents (Account), the sync will fail with FIELD_INTEGRITY_EXCEPTION errors because the parent records do not exist yet in the sandbox. Always assign parent objects lower sequence numbers.

Not disabling automation

Sandbox validation rules and triggers are often different from production. A record that passes all production validation may fail in the sandbox due to sandbox-specific rules added during development. Disable automation before seeding to avoid cascading failures.

Sandbox refresh invalidates the OAuth connection

After a Salesforce sandbox refresh, the sandbox receives a new Org ID. The existing OAuth connection in iSyncSF will fail because the token was issued for the old sandbox. You must disconnect and reconnect the sandbox from the Org Connection page after each refresh.

Not using external IDs

Without a CustomExternalID, every sync run creates new records even if the same data already exists in the sandbox. This leads to duplicate records that are difficult to clean up. Always configure external IDs for idempotent seeding.

Exceeding sandbox storage limits

Developer and Developer Pro sandboxes have limited data storage (200 MB and 1 GB respectively). Use SOQL WHERE filters on template lines to limit the volume of data seeded. For example, seed only Accounts with more than 5 Opportunities, or only Contacts created in the last year.

Forgetting to re-enable automation

After seeding, always return to Automation Control and re-enable all disabled automations. Testing with automation disabled does not reflect real-world behavior and can mask critical bugs.