Tim is a Senior Consultant at ThreeWill. He has 15 years of consulting experience designing and developing browser-based solutions using Microsoft technologies. Experience over the last 8 years has focused on the design and implementation of SharePoint Intranets, Extranets and Public Sites.
I’ve recently been trying to get up to speed on Salesforce to understand how it can best be leveraged to solve business problems. ThreeWill has been using and developing applications with Salesforce for several years, but I had been focused (and still am) on building solutions on the SharePoint platform, so Salesforce was a relative mystery to me. However, in recent years, we have found that many of our customers have both SharePoint and Salesforce, and I wanted to be able to suggest the best platform for the best solution. So, I decided to invest time into learning more about Salesforce.
Around this same time, Eric Bowden and Danny Ryan from ThreeWill began working on a File integration application to allow storage of files related to Salesforce Accounts and Opportunities to be stored in Microsoft 365. I was able to provide some assistance to Eric on this application, so this helped me to get some “real life” experience with Salesforce in addition to the Trailhead training and Pluralsight courses I had been taking.
10+ things that you need to know about getting started with Salesforce development
- Salesforce is not just a product for Marketing and Sales. It is a rich Cloud Platform that can be used to provide business solutions to virtually any part of the business. There are many features available through mere configuration and there are hooks for custom code to help fill in any gaps.
- Learn what you can accomplish using configuration so you only add code when necessary. In general, this should make maintenance less costly and make upgrades go more smoothly. Salesforce does several scheduled upgrades each year and the greatest risk of breakage is in custom code.
- As you architect solutions, remember that Salesforce can access and display data from other data sources and Salesforce data can be accessed by and displayed in other applications. ThreeWill has experience with both. In Chatter for SharePoint, we display Salesforce data within SharePoint. In Trove, we display Microsoft 365 files within Salesforce.
- Research “Gotchas” before they “Get ya” – In all platforms and frameworks, there are “gotchas” or edges that are not apparent. Normally, these are learned as you gain more and more experience developing on a platform. Fortunately, with Google Search, social technical sites, and a number of self-training sites designed to share information, you can leverage the experience of others without necessarily having to experience these pains personally. Dan Appleman covers some very important topics in “Advanced Apex Programming for Salesforce.com and Force.com” as it relates to “Limits” that are enforced in Salesforce to keep the Cloud healthy and responsive for all users. Appleman and other leading Salesforce developers have also produced several training videos out on Pluralsight that cover topics from the book and more.
- Create meaningful Usernames as you create your Salesforce Developer environments (https://developer.salesforce.com). Usernames are formatted as email addresses, but they do not necessarily have to correspond to a real email address. There is a separate email address field that should be populated with your real email address so that you receive emails from Salesforce. So, for example, I can create a username [email protected] to correspond to my Trove developer environment and [email protected] to correspond to my Chatter developer environment.
- Data Access/Data Manipulation in Salesforce is accomplished through a SQL-like syntax called SOQL (Salesforce Object Query Language). This should make for an easier learning curve for those who are familiar with writing standard SQL.
- Apex Triggers are a great way to help maintain data integrity. Triggers can be written to run before or after inserts or updates. Triggers that run before an insert or update can prevent the insert or update if the update would violate a business rule. Triggers that run after an insert or update might propagate data to other Salesforce objects for reporting or other purposes.
- Salesforce has a browser-based development IDE that includes intellisense so there are no 3rd party development tools required or even any tools that have to be installed locally. However, there is no source control natively supported in Salesforce, so more advanced development will probably leverage Eclipse and a source control provider such as TFS or Subversion.
- Custom code written on the Salesforce platform requires test coverage of at least 75%. Salesforce provides a great infrastructure to support and encourage the development of test cases. These test cases are used to ensure that your custom code is not broken during Salesforce Major Releases that happen several times a year.
- Debugging custom code in Salesforce is more rudimentary than what you’ve experienced doing in .Net development with Visual Studio. There is no debug option that involves pausing of real-time execution to interrogate variables. However, you can log these values to a Salesforce log or write your own logging to capture variable values. Another useful tool in debugging Apex code is the Open Execute Anonymous Window under Debug in the Force.com Developer Console. From this window you can execute code to ensure it works properly.
These are some things that have stood out to me as I have been learning more about Salesforce Development. One of the areas I have yet to focus on personally is the application deployment and upgrade process for Salesforce, so I know there are many more things to know as you get started. Feel free to share your own ideas so that we can all benefit. Also, there’s a webinar coming up that will cover getting started with Salesforce Development – please join me for this event.