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

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
Salesforce Certified Developer Exam
Apr24

Salesforce Certified Developer Exam

Read More
Saas Cloud Providers
Apr24

Saas Cloud Providers

Read More
7 Checkpoints for Salesforce Developer
Apr24

7 Checkpoints for Salesforce Developer

As a Salesforce developer you are supposed to take some mandatory precautionary measures for development, testing and deployment. Development in itself could be a complex job. We should be careful enough while we are designing the UI or implementing any business logic. This piece of advice can be a long list of Do’s & Dont’s but I will be summarizing the top 7 domains under which a novice or a seasoned developer can make mistakes. Trigger: Less Code in Trigger: Business logic should be written in Apex classes and purpose of writing a trigger should be to divert the various update, insert, delete, before, after control flows to the correct Apex class. Context-Specific Handler Methods should be their in Apex classes. Bulkification. While developing a fresh trigger we should always think of the possibility that the records in the object can be inserted, updated, deleted by a User in bulk using API, Data Loader tool or custom Multiple edit page etc. NULL Check: This is a very basic check which every developer learns in the course of testing triggers which they developed. One Trigger for One Object: Creating multiple triggers on the same object will cause warnings in Checkmarx code review for Appexchange. Self looping triggers: Beware of this and make sure you use a Static field in class to verify the trigger is not getting called multiple times. Webservice callouts from Triggers: Can’t hit more than 10 callouts at a time. Design Patterns are good solution for this. Trigger Frameworks and Apex Trigger Best Practices Visual Force: SOQL: Make sure the query is having a limit or an intelligent WHERE clause. A query can be written in Salesforce in multiple ways. Design: If the Logic permits then use components and divide the screen in separate pages or Wizard steps. Use Static Resource for all the CSS and images. Separate JQuery, Javascript files will also be good. Check View-state: Make sure that the Salesforce view state size is always in check. Action Tags: The lesser number of action tags the less will be callouts to Salesforce controller(Server). Most of the simple business logic/validations can obviously be carried to client side scripting. Best Practices for Improving Visualforce Performance Web Service: Commit Rollback exception. This should be taken care of SOAP: We should have the clear understanding of WSDL we are going to use in Salesforce. Web Service, parameters, range and return value. SOAPUI is one of the best desktop based tool to do a dummy test. WSDL FILE size limit may some time demand trimming: Will need WSDL expertise for this job. REST: The services resources should be identifiable and...

Read More