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, 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 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 Developer, Administrator or Team Leads will learn and advice their team members to be very careful.


Author: AJ

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *