Bruises Bigger Than Dinner Plates
For those who have had the unfortunate experience of performing a data-load into Salesforce, only to discover the rascally after-effects of having to answer to those who have received unwanted notifications, you are very aware of how incredulous this can be. If the result of this further included end-customers receiving emails (be it test or actual context) then perhaps ‘incredulous’ would likely be replaced by ‘agitation’ or perhaps ‘bedlam’. Through many an admin’s journey, there has been at least one instance of this occurring, and when it occurs (even on a small scale), it is akin to the lesson we learned as kids of putting our hand on a hot stove-top. When it does happen, we likely don’t repeat the same thing again as the lesson has been learned, but if you’ve never had the (dis)pleasure of such an occurrence, there are some simple rules of the road to follow in which to avoid such a calamity.
Perform the work in your Test Environment Salesforce has provided the Sandbox Environment for a reason, so why not use it for its intended purpose? Agreed, the data may not be exactly as what’s on your production version (unless a refresh has just been done), but the peace of mind that it gives you when performing data-loads can drastically reduce the amount of issues
Ensure that the Deliverability option is set to ‘System Emails Only’ or ‘No Access’ If you are performing a data load which does not require a resulting email alert, then turn off the deliverability. However, if you need to see the email alert results of your data-load, use ‘dummy data’ with email addresses that are meant for testing purposes.
Pro-Tip: Consider using a disposable email service such as TempMail or GuerrillaMail which are ideal for testing while at the same time providing a secure, spam-averse experience.
Review your Process Builder, Workflow and Validation Rules which are associated with the Object you are performing the data-load on BEFORE the onset of an Insert / Upsert action. Easier said than done, perhaps… but in reality it takes only a few minutes and unless there are new rules which are being developed during your data-load you need only perform this task once.
Utilize the ‘Power of ’Minimum’ When you have your final CSV file ready to test, instead of loading all of the records in at once, do a ‘Save-As’ and create a second Test-File by removing all of the rows except for the first. If there are any errors (and if your load includes an email address, make sure it’s your own) then the damage will be insignificant in comparison to a full load of hundreds (or thousands) of records. Just this one step, which takes only seconds to prepare may be one of the best defence mechanisms you can take to eliminate anguish.
As a Salesforce professional admin or developer, you are always dealing with tight deadlines and understandably so, things can happen… more so when you’re in a crunch and time is a luxury you can’t afford. If you are a seasoned admin, you’ll know the ramifications of all outcomes when performing a data-load and are always ‘on duty’ when the prospect of a load is required. The same ‘checklist of items’ refrain will be running over and over again in your mind prior to a change / addition of data into your environment. For the greenhorn however, there is no such experience-level that has been realized (yet), and if this is your first time to the party, take a tip from the veterans who have been at this juncture just too many times as they will plead with you to mechanically go through the steps initially so as to learn how these mistakes can be avoided altogether. Remember, Salesforce doesn’t have a conscience and will do whatever you tell it to, and like a tempest, can inflict destruction at the most inconvenient times. It’s no different really than any other life-lesson which if a sense of preparedness and practice are paramount, the result will be that of cool heads and an intact ego.
Title image by HD Wallpapers | Quote by Morrissey / The Headmaster Ritual
