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 a 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. The reader is expected to have some prior knowledge of Salesforce so that this blog makes 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 taken 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 done 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 says 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 that was using the sales cloud in salesforce. They’re in house developers were already neck-deep in developing several features. We were given some bugs to fix in a 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, Opportunity Line Items, Quote Line Items, was custom developed and the Salesforce standard objects were not being used. We were surprised to see this. Instead of fixing the code we spend the time in finding the reason behind this stupidity. Eventually, bugs were fixed in the custom object but the true sense of Custom Sales Process creation was never found and also not the Architect who planned all these. LESSON LEARNED: Always make sure that the solution designed is getting peer-reviewed by a different team. Such mistakes can be committed by developers who don’t know Salesforce out of box solutions.
Sales cloud
With these 2 stories I expect other Salesforce Developers, Administrator or Team Leads will learn and advise their team members to be very careful.
Recent Comments