#iSyncSF FAQ – Common Questions & Error Solutions

Q: How do I handle DmlException when inserting records in Salesforce bulk operations?

iSyncSF uses allOrNone=false for all bulk DML operations, which allows partial success — records that pass are committed while records that fail return a SaveResult with the specific error. Every failure is written to DataSyncAuditLog with the error message and source record ID. Failed records can be retried from the Execute tab without reprocessing the entire dataset.

Q: Why do I get 'Too Many SOQL Queries: 101' during Salesforce batch processing?

System.LimitException: Too many SOQL queries: 101 fires when more than 100 SOQL queries execute in a single transaction. In sync operations this typically happens when relationship resolution queries run per-record inside a batch. iSyncSF resolves all parent-child ID relationships in bulk during the pre-scan phase — before any DML — eliminating per-record SOQL lookups. Reducing MaxBatchSize in Object Settings also lowers SOQL consumption per transaction.

Q: How to roll back a Salesforce data migration if something goes wrong?

From iSyncSF's Sync History tab, locate the completed sync job and click Rollback. iSyncSF deletes records that were inserted into the target org during that job. If DataVersion versioning was enabled at the time of the sync, updated records are also restored to their pre-sync values. Rollback is scoped to a specific job — it does not affect records from other sync runs.

Answers to the most frequently asked questions about iSyncSF, covering general usage, common Salesforce sync error codes, parent-child relationship handling, and configuration topics.

#General Questions

What is iSyncSF?

iSyncSF is a Salesforce managed package that copies, migrates, and synchronizes data between Salesforce orgs. It connects a source org to one or more target orgs using OAuth or Named Credentials, then transfers records according to templates you configure — with field mapping, data masking, picklist translation, and rollback built in. Common use cases include production-to-sandbox seeding, org consolidation, and ongoing incremental sync.

Can I use iSyncSF for production-to-sandbox data seeding?

Yes. Production-to-sandbox seeding is one of the primary use cases. Configure a template pointing at your sandbox as the target org, enable Data Masking on sensitive fields so PII is anonymized before it reaches the sandbox, and use a CustomExternalID so repeat runs are idempotent. See the Sandbox Seeding use case guide for a complete step-by-step walkthrough.

Does iSyncSF support incremental (delta) sync?

Yes. Enable the Delta Sync option on the template. iSyncSF records the Last Sync Date after each run and uses it as a filter on the next run — only records modified after that date are included. You can override the Last Sync Date manually on the template record to reprocess a wider date range.

Can I schedule iSyncSF to run automatically?

Yes. iSyncSF includes a built-in scheduler (DataSync Job Manager) that runs hourly and resumes any sync jobs that are queued or paused. You configure the sync to run on a schedule by setting up the scheduled job from the Setup Assistant's Scheduled Jobs tab. The scheduler enforces a concurrency limit so no more than five sync jobs run simultaneously.

Is there a record limit per sync job?

The record limit is controlled by your iSyncSF license tier (visible as the Records Limit feature parameter). Within a single sync run, iSyncSF processes records in batches — the batch size is configurable per object via the MaxBatchSize field on Object Settings. The ExternalMaxbatch setting on the template controls how many records are sent to the target org per callout.

#Sync Errors & Troubleshooting

Why is my Salesforce data sync failing with FIELD_CUSTOM_VALIDATION_EXCEPTION?

FIELD_CUSTOM_VALIDATION_EXCEPTION occurs when a validation rule in the target Salesforce org rejects an inserted or updated record because the incoming data does not satisfy a field condition. iSyncSF logs every validation failure to the DataSyncAuditLog object with the full error message so you can identify which rule is firing and on which records. The ContinueOnError option on the sync template controls whether the job halts or skips and continues past validation failures.

Resolution: Use Automation Control to disable the validation rule in the target org before the sync, or add an Object Field Mapping expression to supply a valid value for the failing field.

How do I sync data between Salesforce production and sandbox without validation rules firing?

Use iSyncSF Automation Control to disable validation rules in the target sandbox before running the sync, then re-enable them afterward. Alternatively, configure the integration user profile in the target org to bypass specific validation rules using $Profile.Name conditions. iSyncSF Automation Control handles this through the Salesforce Metadata API without requiring manual clicks.

What causes INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY during Salesforce data migration?

This error means the running user in the target org does not have read access to a record referenced by a lookup or master-detail field on the record being inserted. This is a sharing model issue — the referenced record exists but the integration user cannot see it due to private OWD settings or role hierarchy restrictions. Configure the Org Master record in iSyncSF to use a DefaultUserID with sufficient access, or review the target org's sharing model for the affected object.

How do I handle DmlException when inserting records in Salesforce bulk operations?

iSyncSF uses allOrNone=false for all bulk DML operations, which allows partial success — records that pass are committed while records that fail return a SaveResult with the specific error. Every failure is written to DataSyncAuditLog with the error message and source record ID. Failed records can be retried from the Execute tab without reprocessing the entire dataset.

Why do I get "Too Many SOQL Queries: 101" during Salesforce batch processing?

System.LimitException: Too many SOQL queries: 101 fires when more than 100 SOQL queries execute in a single transaction. In sync operations this typically happens when relationship resolution queries run per-record inside a batch. iSyncSF resolves all parent-child ID relationships in bulk during the pre-scan phase — before any DML — eliminating per-record SOQL lookups. Reducing MaxBatchSize in Object Settings also lowers SOQL consumption per transaction.

How to fix REQUIRED_FIELD_MISSING when copying Salesforce data between orgs?

REQUIRED_FIELD_MISSING means a field required in the target org was null in the source data or not mapped in the template. Fix this in iSyncSF by adding an Object Field Mapping record for the affected field with an Expression value that provides a default (e.g., a hardcoded string or conditional formula). The DataSyncAuditLog identifies exactly which field is missing on which records. See Field Mapping & Expressions for expression syntax.

What is DUPLICATES_DETECTED in Salesforce and how do I handle it during data migration?

DUPLICATES_DETECTED fires when a Duplicate Rule in the target org matches the incoming record against an existing one. iSyncSF handles this through the upsert strategy — set a CustomExternalID on Object Settings to match records by an external ID field, which triggers an update instead of insert and bypasses duplicate rule evaluation on insert. Alternatively, disable the duplicate rule in the target sandbox before syncing using Automation Control.

How to migrate Salesforce data without triggering automation rules?

Use iSyncSF Automation Control to disable Flows, Apex Triggers, Validation Rules, and Workflow Rules in the target org before the sync, then re-enable them after. This is the most reliable approach for bulk data loads where automation interference causes failures.

Why does my Salesforce data sync show records inserted but not visible in target org?

Records may exist but be invisible due to sharing rules — if OWD for the object is Private and the integration user owns the records, only the owner and users above in the role hierarchy can see them. Check iSyncSF's DataSyncAuditLog to confirm the records were committed (check the StatusCode, Destination_Record_ID__c, and HasError__c fields) and get their target IDs for direct lookup. If they exist and are invisible, review the target org's sharing settings for that object.

How to roll back a Salesforce data migration if something goes wrong?

From iSyncSF's Sync History tab, locate the completed sync job and click Rollback. iSyncSF deletes records that were inserted into the target org during that job. If DataVersion versioning was enabled at the time of the sync, updated records are also restored to their pre-sync values. Rollback is scoped to a specific job — it does not affect records from other sync runs. See the Rollback documentation for full details.

What does MIXED_DML_OPERATION mean in Salesforce and how to avoid it?

MIXED_DML_OPERATION fires when Apex code performs DML on a Setup object (User, PermissionSet, Group) in the same transaction as DML on a non-Setup object. iSyncSF's sequential job chaining processes each template line in its own batch transaction, naturally isolating Setup and non-Setup object operations when template lines are ordered correctly. Ensure that template lines containing User or PermissionSet objects are in separate sequence positions from standard object lines.

How to map fields between different Salesforce orgs with different picklist values?

Use iSyncSF's Picklist Value Mapping feature in Object Settings. Create PicklistValueMapping records that define SourceValue and TargetValue pairs for each field. iSyncSF applies these translations during sync — before any DML is attempted — so restricted picklist fields in the target receive only valid values. See Object Settings for configuration steps.

Why is Salesforce sync failing with CalloutException: Exceeded max size limit?

System.CalloutException: Exceeded max size limit of 12000000 means the HTTP response from the target org exceeded Salesforce's 12MB callout limit. Reduce the ExternalMaxbatch setting on the sync template to send fewer records per callout. For objects with large text or rich text fields, reduce batch size further to keep payload size under the limit. This setting is on the template's main configuration, not the Object Settings.

How to sync parent-child records in Salesforce without breaking relationships?

iSyncSF handles parent-child relationship ID remapping automatically. The pre-scan phase analyzes the object hierarchy, determines insertion order (parents before children), and maps source parent IDs to their new target IDs. Child records are populated with the correct target parent IDs before insert — you do not need to manage this manually. Ensure that parent objects appear in earlier Sequence positions in the template than their children.

What is the safest way to seed a Salesforce sandbox with production data?

The safest sandbox seeding approach with iSyncSF is: (1) run Preview/Scan first to validate record counts, (2) enable Data Masking for PII fields so sensitive data is replaced before reaching the sandbox, (3) use a CustomExternalID for upsert so re-runs are idempotent, (4) use Automation Control to disable validation rules and triggers in the sandbox, and (5) keep the Rollback option available in case the seeded data needs to be cleared. See the full Sandbox Seeding guide.

#Parent-Child & Relationships

Do I need to manually manage the order in which parent and child records are synced?

iSyncSF computes the insertion order automatically during the scan phase. However, you do need to ensure that parent objects are assigned lower Sequence numbers than their children in the template lines. If a parent has a higher sequence number than its child, the child will try to insert before the parent exists in the target and will fail with a FIELD_INTEGRITY_EXCEPTION.

What happens if a parent record fails to insert and a child record depends on it?

When a parent insert fails, the audit log records the error on the parent row. iSyncSF does not automatically cascade the failure to child records — child records will attempt to insert and will fail with a lookup resolution error (FIELD_INTEGRITY_EXCEPTION) because the parent ID does not exist in the target. The ContinueOnError flag on the template determines whether the job continues processing remaining records after these failures. Use the retry function on the Execute tab to reprocess failed records after fixing the root cause on the parent.

How does iSyncSF handle self-referencing (hierarchical) objects like Account parent-child hierarchies?

iSyncSF has dedicated handling for self-referencing objects. During the scan, it computes the depth of each record in the hierarchy and assigns sub-sequence numbers so that top-level records are inserted first, then each subsequent level. For very deep hierarchies, ensure the MaxSubOrderLevel system property is set high enough to cover all levels. If you encounter issues with deep hierarchies, the System Configuration Reference explains the relevant properties.

Can I exclude certain lookup fields from being remapped to target IDs?

Yes. Use the Exclude Parent Fields setting on the Object Settings record for the child object. This prevents specified lookup fields from being included in the parent ID remapping process — useful when a lookup points to an object that you are not syncing and the target already has the correct record (for example, a RecordType or a User record that exists with the same ID in both orgs).

#Configuration & Setup

Where do I configure the connection between source and target orgs?

Org connections are managed on the Org Master object and configured through the Org Connection tab in the iSyncSF app. You can connect using OAuth Web Server flow (which stores an access token) or Named Credentials. The Setup Assistant walks you through the initial OAuth setup including creating the Connected App configuration.

What is the difference between a Template Line and Object Settings?

A Template Line defines which records to include (the object API name and a SOQL filter or ID list). Object Settings (the Advance Tab) define how to process those records — field mappings, matching keys for upsert, batch size, data masking configuration, and picklist value translations. You can have multiple template lines referencing the same object with different filters, each pointing to the same or different Object Settings.

How do I prevent iSyncSF from overwriting existing records in the target org?

Set UpdateExistingRecords to false on the Object Settings record for that object. When a match is found via the external ID or mapping key, iSyncSF will skip the record (logging it with status "Existing") rather than updating it. To also prevent inserts on already-matched records, combine this with a CustomExternalID that will match on existing records.

Can I run iSyncSF without affecting the target org's automation (triggers, flows)?

Yes. Use Automation Control to selectively disable specific automations in the target org before the sync. iSyncSF communicates with the target via the Salesforce Metadata API to toggle automation on and off. After the sync completes, re-enable the automations from the same tab. This requires the integration user to have Metadata API access in the target org.

How do I check what went wrong after a sync job fails?

Start with the DataSyncAuditLog — navigate to the sync job record and open the related audit log list. Filter by HasError__c = true to see all failed records. The ErrorMessage__c field contains the exact Salesforce error. For higher-level operational errors (connection failures, batch crashes), check the Application Logs tab. See the Troubleshooting Guide for a structured diagnosis approach.