The most dreaded technology

The 2015 Stack Overflow developer survey results are published and this year the most dreaded technology was Salesforce.

If you are getting started with Salesforce as a developer don’t panic. I’ve recently completed a large integration project and I’ll try to highlight some of the things I’ve learned along the way. I’m not an expert so take my advice for what it is. I’m just a random guy on the intranet blogging for fun.

Before working on a feature review any Salesforces limitations in that area. It’s pretty easy to find the documented limitations like execution and governor limits and data storage but some limitations might not be so easy to find. For example, if your company uses emails with image attachments. The email to cases feature of Salesforce might not be the best choice. I found Salesforce’s image handling in cases was very poor. The images are taken out of the HTML email and added as an attachment. It turned out to be too painful to use. A few more examples are that Salesforce doesn’t support accented email addresses and no helper class for creating GUID/UUID. You will find many of these hidden limitations as you dig into a particular problem. It’s good idea to check into all the details before giving too low of an estimate on your development time.

Data storage is expensive so make sure it’s used efficiently. Avoid writing code that generates custom objects unnecessarily and look into using objects like chatter which don’t count against your data storage limits.

Carefully consider how you use triggers and workflows. You can quickly get into a unnecessary complexity if you use triggers to solve all your problems. If what you are trying to accomplish needs to happen for users and automated integration points a trigger might be a good choice. If some event is only going to happen because of messages/events from your internal system to update a few objects then you would be better off building an Apex rest endpoint. If you find you are spending hours and hours debugging triggers consider how you could handle the problem in a different way. For example, my company’s lead conversion process was very complicated and originally implemented using multiple triggers to merge, handle duplicates, round robin assignment, and verify company associations. It turned out to be easier for us to build our own system to do lead conversions and not use the lead object in Salesforce. Leads ended up just being sent to our internal system via outbound messaging and converted when the process completed using an Apex Rest endpoint.

If you don’t have developers with Salesforce experience and you plan to do lots of automation and custom development I would suggest hiring an experienced Salesforce developer to work with the development team for a few weeks. This will help jump start your dev team by giving them some good examples to follow. Don’t hire a consultant and let them run with it. Make sure you give them very specific tasks and be clear that you want them to show you how to write good Apex. Challenge them to explain why the code should be bulkified or not. Have them show you how to avoid using “all data” tags in your tests. Make sure the tasks given to a consultant are well defined and would only take a week to finish. An example task might be writing a trigger handler that automates business logic when an object is updated or inserted by a users or any integration points.

Before you get to far along with your first feature learn some of the tools of the trade. Workbench, bulk API, bulk Apex jobs, SOQL, developer console, and sandboxes. When getting started I would also suggest using source control. You can find lots of references on how to get all the meta data pulled down using ant. If you have ultimate edition each developer could work in a private sandbox to avoid stomping on each other’s work.

Browse the training videos to get a handle on what features you can use out of the box. You can create a developer account for free which can be used to build a quick prototype or explore Salesforce functionality. Make sure you understand the concept of roles, profiles, access hierarchies, custom objects, custom apps, visual force pages, approval processes, triggers, workflows, validation rules, oauth connected apps, and SOQL.

Suggested training videos

1. Building Applications with Force.com – Part 1
2. Building Applications with Force.com – Part 2
3. Administration Essentials for Experienced Admins
4. Getting Started: Administering Salesforce
5. Getting Started: Navigating Salesforce