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 used for a small interval of time and deleted after testing. We should also have a backup of the database as well and a back up plan if something goes wrong. How fast can we recover is the key to escape from this mistake.
Serious Things Can Happen In Funny Ways: Change-Set Field Override
- STORY: In an existing project we were having several small development and deployment phases. We were supposed to deploy several pieces components were getting deployed every week. End Client were already using the Salesforce production environment with few Account, Contact, Opportunity records. We received an urgent requirement by the client to modify a Contact field Type. It was earlier a picklist and they wanted it to be a Text field. It was a simple and quick change. The next release was on date and we packed the change-set with several other changes and did the deployment.
Only convert custom fields for which no data exists or you risk losing your data.
- MISTAKE: We updated the field data type in sandbox and moved it to production in a collective changeset with lot of other components. Since the field Data Type was changed so the production Contact records field value was deleted in process of the Field Type update.
- LESSON LEARNED: When moving any Data Model changes in production make sure you have a copy of the existing database or at least the existing fields which are about to be modified. Avoid updating the Data Type directly if the records are having values in them and rather than doing a field type update its wise to create a new field with datatype and do the data migration to the new field.
With these stories I expect other Salesforce Developer, Administrator or Team Leads will learn and advice their team members to be very careful.
Recent Comments