Apply Seeding Best Practices
Learning Objectives
After completing this unit, you’ll be able to:
- Apply best practices for managing test data.
- Identify common job issues and describe solutions.
- Describe limitations of Seeding’s functionality.
Best Practices for Managing Test Data
To ensure an efficient and successful seeding process, follow these best practices.
Understand Your Schema
Thoroughly review your Salesforce schema, paying close attention to object relationships and the specific objects you plan to seed. This is a critical first step that greatly increases the likelihood of a successful data population.
Optimize Your Destination’s Metadata
Before replicating records, especially older ones, ensure the destination org structure can accommodate the incoming data. This includes checking for proper record types, picklist values, and dependencies to prevent Salesforce errors.
Streamline Template Design
Avoid redundant root objects. Seeding intelligently prevents duplicates even if an object appears multiple times in a template. Child objects automatically inherit filters on root objects, simplifying your configuration.
Manage User Objects
Seeding's smart automation handles user objects for you, so you generally don't need to manually include them.
- Automatic Cloning: User records are automatically cloned during sandbox creation and during sandbox refresh to prevent permission errors.
- Mapping: Standard users from Salesforce refreshes are mapped by their email.
- Unmatched Users: Users in the source but not the destination are mapped to the authenticated user.
- Adding Missing Users: If your organization needs to add missing users, you can add the user object to a Nodes template, which is exclusive to that type.
- Excluded Types: Certain user types, like Owner and Case Team contacts, are not automatically cloned as they don't affect the seeding process.
Common Job Issues and Solutions
When running Seeding jobs, you can encounter errors related to data integrity and permissions. Below are some examples.
Common Errors
- Invalid Cross-Reference Key: A referenced parent record is missing from the Seeding job, or the authenticated user lacks the necessary permissions.
- Deleted Entity: A source record refers to a record that has been deleted in the destination.
- Picklist Value Error: A picklist value from the source is not enabled or is no longer active in the destination environment.
Solutions
Here are some suggestions to address these issues.
- Ensure all referenced parent objects are included in your template.
- Verify that user permissions are correct for all relevant objects and record types.
- Confirm that all necessary picklist values are active and enabled in the target environment.
- If manual data changes have occurred in the sandbox, select “re-indexing” when seeding to your destination to allow Seeding to reference the existing records in your sandbox.
In addition to data integrity errors, you might also encounter issues with automations, duplicate data, or field limitations:
Salesforce Automation Errors
- Cause: Generally active triggers or validation rules in Salesforce prevent data insertion or updates.
- Solution: Consider temporarily disabling automations during the seeding process or modifying your template or dataset to comply with the active automations.
Duplicate Data Errors
- Cause: Salesforce generates an error if it finds a matching unique identifier during a record insertion or update.
- Solution: Enable indexing for reviewing exiting data in the destination; or, use Field Mapping to map by unique field value and not by record ID.
Limitations of Seeding Functionality
While Seeding is a powerful tool, it’s important to be aware of certain limitations that can affect your data seeding strategy.
The application currently does not support the seeding of several object and field types, including but not limited to:
- Big objects
- Calculated fields (formula)
- Chatter objects
- External objects
- Case article objects
- Tags
Levels Template Limitations
Keep these limitations in mind when using Levels templates.
- Attachment and Content Handling: Attachments and content documents are skipped during the seeding process (they are not seeded or replaced with placeholder files).
- Batch Size: You cannot reduce the batch size for a Levels template.
- Object and Field Support: Certain objects and fields are not supported, including AgentWork, Calendar, and FeedItem objects.
- Non-Mandatory Parent Objects: While mandatory parent objects are automatically included, non-mandatory parent objects can only be added to a root object within the template.
General Seeding Limitations
These limitations apply more broadly to the seeding process:
- Data Volume: There are inherent volume limits on the number of root records in a single job and the total number of objects in a single template.
- Large-Scale Solutions: For very large or complex data volumes, you may need to split jobs or simplify your templates to ensure optimal performance.