Frequently Asked Questions

What metadata is modified in the Target Org during a Transfer?

  • We temporarily turn off Triggers, Workflow rules, Validation Rules and Email Deliverability.
  • Process Builder is not supported at this time, but it is on our roadmap.
  • We only turn off metadata that is related to objects which have records to insert.

What happens with records owned by Portal/Community Users?

Since Portal Users are not transferred by Salesforce, we can’t insert records that have lookups to them.

What happens with records owned by Inactive Users?

This is a very common reason for records to fail during insertion. We may filter out records owned by inactive users from our SOURCE queries in a future release.

I need to “sterilize” some data like email addresses. Is that possible?

Our recommendation is to do the transfer into a developer sandbox, then modify the data there using dataloader. After that, you can use that sandbox as the SOURCE for future sandbox refreshes.

Can we transfer User records?

Not at this time.

Can you move data between org hierarchies?

For example, can you transfer between sandboxes belonging to different production orgs?

Not currently.  Although it’s technically possible if the schemas are identical (objects and fields), transfers will fail because things like UserIDs and RecordTypeIDs are not consistent between Org Hierarchies, so they will fail on insertion.

Why does email deliverability get turned off?

In case there are workflow or process builders that fire emails, we safeguard by turning off deliverability.

Common Transfer Errors

Operation performed with Inactive User as Owner

The record that’s being transferred is owned by a user that’s inactive in the Target. To resolve it, you can utilize our “Replace Inactive Owners with Running User” feature which can be accessed on the Customize menu under Transfer Objects, shown below. Alternatively, you can activate the user(s) in the Target and re-run the transfer.


Note that you can reply to any Success Email requesting a job to be re-run with this setting enabled.

The record couldn't be saved because it failed to trigger a flow.

This error is typically caused by a flow that cannot be run on a particular object when a record is inserted. Since SmartSandbox automatically turns off active Flows on Transfer Objects, this error is most often caused by the following:

  1. A transfer object has a trigger in a managed package, which cannot be disabled
  2. That trigger attempts to insert a record into a separate object, which is not a Transer Object
  3. A flow fails to fire on that separate object.

To resolve this, we suggest investigating the particular flow based on the Flow ID in the error message, and potentially disabling it during the data transfer.  Additionally if you are using the Non-Profit Starter Pack, review our Knowledge Article about NPSP triggers.

Field Filter Validation Exceptions

This is caused by a field-filter value that is invalid in the Source. To correct it, you can either fix the data in the source or modify the Field Filter in the target.

Converted Lead Records

Converted Leads cannot be inserted.

Have other questions?  Contact us and we’ll get back to you ASAP.