Its wise to learn from other’s mistakes: P3
Apr30

Its wise to learn from other’s mistakes: P3

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 3 in the series of blogs Part 1 & Part 2 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.   Always Aim At Right Direction: Connections and Mapping STORY: We have recently take over a project which was being developed by another team in JitterBit. We were very much confident since we had earlier developed similar features and have successfully did a bidirectional data transfer from salesforce to another platform. We were Change Sets Overview supposed to login and start the trial connection and push some trail data in Sandbox. On the very first day of the project we logged in and started the cron job. As earlier explained by the developer that the settings and connections were mapped to the Salesforce sandbox environment and all the testing and dummy push can be done directly and when Go live will be required we can change the connections and Mapping to Live environment. MISTAKE: We started the trial push without verifying anything and data was pushed to salesforce production since the Jitter Bit connection was mapped to production. BOOM!  We got hit by a Train. Production data was overridden. LESSON LEARNED: Never believe on what any developer say if the topic/matter is related to Salesforce production. Always double check and verify before doing any kind of Connection based testing.   Re Inventing The Wheel: Creating Salesforce Out of Box Features. STORY: We got an opportunity to work for a company who was using the sales cloud in salesforce. Their in house developers were already neck deep in developing several features. We were given some bugs to fix in certain time period. In order to understand the underlying enhancements already done by the last developers I made sure that we spend enough time in analyzing WHAT changes were done and WHY? MISTAKE: The Salesforce Enterprise org was having salesforce Standard objects recreated as custom. In fact the entire Sales model with Opportunity, Product, Quote,...

Read More
Its wise to learn from other’s mistakes: P1
Apr26

Its wise to learn from other’s mistakes: P1

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...

Read More
Saas Cloud Providers
Apr24

Saas Cloud Providers



Read More
Salesforce Certified Developer Exam
Apr24

Salesforce Certified Developer Exam

Read More
Its wise to learn from other’s mistakes: P2
Apr05

Its wise to learn from other’s mistakes: P2

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 2 in the series of blogs Part 1  & 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. A Mistake That Can Ruin Your Career: Database Update Query STORY: We had one client with a history of several small projects. Client is big in Construction Specialties manufactures and sells specialty architectural products internationally. They are using Salesforce to manage their entire service process and partially their sales process in Salesforce. The product management was being done in Microsoft SQL.  This was a unidirectional communication between Salesforce and the MSQL product database. We have developed a third party integration between Salesforce and MSQL Server based on Java technology. The storyline was whenever a particular Quote or Quote line items in Salesforce gets updated or created the information was being send to the Microsoft database using the SOAP callout message from Salesforce. Everything was running smoothly but one day couple of quotes went out of Sync, so we were supposed to test and find the bug in them. MISTAKE: Developer was new in the Salesforce team and he had earlier worked on the similar kind of projects but this was his first week. I assigned him the task of testing so that he could easily understand the internal integration, the working of the functionality etc. Now in order to test he was supposed to create a sample Quote in MSQL database and was supposed to sync it from Salesforce. The mistake which he did was instead of creating a single quote and then updating it with the corresponding Salesforce id he updated more than thousand quotes with the single Salesforce Quote Id.  we don’t know what exact SQL query was fired until we tracked down history scripts. LESSON LEARNED: When creating dummy records any where we should be extra careful. We should avoid creating test records in Production but its not avoidable at all then the records are supposed to be...

Read More