When managing data in Salesforce, knowing how to handle bulk data uploads efficiently and safely is crucial. In this post, we'll dive into best practices every Salesforce Admin should master to ensure data integrity and efficient processes.
Dataloader
First, use Dataloader. This can be the downloadable application for desktop or the website dataloader.io. Both are good options, but the downloadable application doesn’t have a pay gate and if you plan on loading a significant amount of data then it will restrict you without extra budget. The downloadable application data loader is the most popular application and by far the most robust application. Get to know it well.
Game Plan
Taking the time to put together a game plan will be more than worth it. Data is one of the “an ounce of prevention is worth a pound of cure” type of activities. Start by answering the following questions:
Who will this data affect?
Does this need to be done out of working hours?
How hard will it be to undo this change?
How will I measure success?
That last question is the most important one. Its significance is important enough that we've dedicated an entire section to it later in this article. But ensuring you have confident answers for all of the above questions and you’ve reviewed this walkthrough you should then be in good shape to proceed.
Back up Everything
Our next step causes the most regret when not done. This is because you can’t access data that no longer exists. It’s hard to revert something when it’s gone forever. Always back up a version of whatever you’re changing. It’s recommended that you use a naming convention. You’ll want to include enough information in the name to remember what it was for 3-6 months later when you’ve completely forgotten. Remember to include the object(s), date and time, type of load, and anything else you think is important. We like the following format:
Account Export - MM-DD-YYYY - Description
Remember, backup, backup, backup!
Storage Space
Creating a specific storage space and folder for all the data loader activity is important. First, you need a place to store your backups. But also, having a single location for all the data files is crucial to ensure you can build a story about what data was loaded and when. For example, let’s say you wanted to trace back a bunch of opportunity products that were backfilled from another system. You’d need to know where the old products came from, the logic used to convert them into uploadable files, if any errors or successes occurred, and if there were multiple attempts to upload them. All of these can be cataloged and accessed through online file sharing. Choose a consistent file location and structure that is used for the whole team.
Handling Automation
Once all the files have been setup for storage, you’ll want to understand the automation dependencies for the data you’re uploading. This could be a lot of different things, but most common are validation rules and flows. The most important reason to address these items is you could upload perfectly pristine data, but then half your data isn’t uploaded due to some error and the other half that was uploaded is different than your original file because of some automation changing it as soon as it’s uploaded.
For example, if you’re backfilling some close won opportunities from last year but there’s validation that you’re not allowed to put in close dates in the past, then all your data is going to fail to be uploaded. Also, if you have automation that changes the closed date to today whenever an opportunity is closed won then all of your close dates will be today and not a year ago. These are very common errors and can be handled a number of different ways:
Turn it all off temporarily
Add a data loader exception for certain users
Adjust the data accordingly to the rules that you’ve set before upload
Most of the time you’ll be using some or all of these simultaneously. The best practice is to use your game plan to address these issues before uploading.
Check your work
Understand how you are going to show that your data load was successful. The most common method that is used is to smoke test a few records and ensure the data exists as expected. However, this is only a first step. You’ll also want to create reports with stakeholders for the scenarios you’re uploading the data to confirm the expected outcomes. There should be concrete numbers spelled out and expected. This will allow you to know on a large scale by percentage the success rate of the data transformation. Checking 2 or 3 records out of 10 provides a high probability of success, but checking 2 or 3 out of 30,000 records doesn’t. Only thorough reporting will provide insights at such large scales.
Final Words
By following the above steps and best practices, you can ensure successful uploads and easily undo data loads. However, this advice is only beneficial if you put it into practice. More often than not the pressure put on you for speed exceeds the due diligence needed for successful uploads. Use these lessons to ensure you get things right the first time.