Since the dawn of Software development, It has been a tedious job to avoid technical mistakes. Developers being human can commit mistakes. By sharing these few mistakes we as a developer make sure that we are learning and helping others avoid such problems.
This is PART 1 in the series of blogs Part 2 & Part 3 I am writing to explain few of my mistakes, blunders or stupidity which I have committed in some of my projects. The mistakes were committed in different roles as a Developer or Consultant or Administrator. Reader is expected to have some prior knowledge of Salesforce so that this blog make some sense. It will be great if you have an understanding of how the various components are developed in Salesforce. A Salesforce Administrator or Developer is surely going to appreciate this blog.
Sometimes Even a Simplest Job Can Be Difficult: Automated Send Email FROM Address
- STORY: We had worked on a small project which was related to a survey conducted by our end client. This Survey was supposed to receive information from already registered users on Salesforce communities and information was to be stored in a Salesforce object. Once a particular User submits his/her information they should be able to receive a confirmation e-mail back. With this requirement in hand we started the development in salesforce sandbox. We were responsible for end to end development, testing
and deployment. We were able to record of the information being entered by a registered user in Salesforce and e-mails were also been send out back confirming the survey information was being successfully submitted in Salesforce. Everything was working as expected in testing and in the deployment phase we moved the components to production.
- MISTAKE: Once everything was live and users were filling up the forms we discovered a mistake. One of the users who have filled in the form and received the confirmation email had replied back to that email. The reply was recieved in my inbox rather than the Client’s support email. Then we quickly did some testing and discovered that registered users were receiving the confirmation e-mail from the developer’s Email ID rather than Client’s support email. So the mistake was that We forgot to update the e-mail sent from the clients registered support e-mail All the registered users were receiving email from Salesforce and with the developer’s email in CC.
- LESSON LEARNED: We should always use the end client’s email for FROM address under Salesforce Email Administration > Organization-Wide Email Addresses for development, testing and deployment.
Email Rainfall Everywhere: Email Delivery Testing
- STORY: We had recently developed Salesforce communities for our Client who was interested in end client management with mass emailing capabilities. For internal Users/Sales Reps who were registered as Salesforce Users, out of box Salesforce e-mailing was being used. The problem client was facing was duplicate e-mails being sent to the internal users from Salesforce and it was becoming very difficult to find out whether the e-mails were being sent from workflow rules or from trigger or any other piece of code. Users were receiving more than one mail with same subject and same content so our Job was to find out this issue and fix it.
- MISTAKE: We tried our best to find out the issue in sandbox but failed and decided to look for the issue in Salesforce Production org. While testing on why duplicate e-mails were being sent from Salesforce unknowingly our developer triggered a particular event in Production which sent out more than 500 e-mails to the internal Salesforce Users. Soon we came to know about the panic and surprize since everyone was wondering why they were receiving such emails.
- LESSON LEARNED:. We should never run a script or trigger a workflow rule in live environment(Salesforce production) where the e-mails of the end users are being used. Testing should always be done in Salesforce Sandbox where the e-mail ids are by default overridden incorrectly so that no e-mails can be sent while testing, development or bug fixing.
With these 2 stories I expect other Salesforce Developer, Administrator or Team Leads will learn and advice their team members to be very careful.