You are here:
Considerations for Salesforce Spiff Sandboxes and Change Sets
When working with Salesforce Spiff sandboxes and change sets, keep these considerations in mind.
Required Editions
| Available in: both Salesforce Classic (not available in all orgs) and Lightning Experience |
| Available in: Enterprise, Unlimited, and Developer Editions |
| Available for an additional cost in: Professional Edition with Web Services API Enabled |
- Spiff sandboxes support at least 100,000 records, regardless of your license count. If your environment exceeds 100 licenses, multiply that number by 1,000—up to a maximum of 1,000,000 records. For example, 250 licenses yields a 250,000-record limit, while 1,500 licenses caps at 1,000,000.
- A Spiff sandbox can use a different Salesforce connector than its parent environment.
- If you include a deleted container item, such as a folder, in a change set, Spiff deletes all container item contents, such as worksheets, in the parent environment. Only the deleted container item appears in the change set log.
- The System Activity Log in the parent environment associates a deployment with the deployer, not with the user who made the changes in the sandbox. For information about who made specific changes in a sandbox, review the System Activity Log in the originating sandbox. See System Activity Log.
- When you select changes in a sandbox to include in a change set, Spiff identifies the records modified in the parent environment but not in the sandbox as a deletion.
- If you make identical updates to the same record in both the parent environment and the sandbox, Spiff reconciles them when the name and value match. These reconciled items appear in the Unique Records Linked section of the change set.
- You can only sync a sandbox manually.
- If a calculation is in progress when a change set deployment begins, Spiff doesn’t block the deployment. Because Salesforce Spiff processes calculations as a queue of individual statement runs, each job captures its data the moment the job starts. If a deployment occurs mid-calculation, then jobs that started before the deployment complete with the data that existed previous to the deployment, and jobs that started after the deployment complete with the data introduced by the new deployment. There’s no way to distinguish which statements calculated with the old data versus the new data within the same run. To ensure data integrity and guarantee that every statement reflects the updated deployment data, restart the calculation after the deployment fully completes.
Did this article solve your issue?
Let us know so we can improve!
