Salesforce has gotten a lot of hype the last few years. In this blog, I will describe Salesforce from the point of you of a Software Engineer. In those same eyes, I will list its pros and cons, and some ways you can mitigate those cons. I’ll also answer some common questions a Software Engineer may have?

1. What is Salesforce?
2. Why should I use Salesforce?
3. Is it worth it for my career to learn Salesforce?

What is Salesforce

First, let me get this out of the way, before the trolls come-a-trolling. Salesforce is of course a company based out of San Francisco. In this blog, though, when I say Salesforce, I mean their Salesforce CRM platform.

The typical descriptions tend to target your Sales, Customer Service, and Marketing departments.

The following is Wikipedia’s description

Salesforce.com is a cloud computing company headquartered in San Francisco, California. Though its profits come basically from acustomer relationship management (CRM) product, Salesforce also tries capitalizing on commercial applications of social networking through acquisition. As of 2015, it is one of the most highly valued American cloud computing companies with a market capitalization of $50 billion,^{[6][not in citation given]} although the company has never turned a GAAP profit since its inception in 1999.

This definition describes the system for typical users; to me, Salesforce is a web application that allows you to track data (i.e. business opportunities, customer support cases) through businesses processes, adding relevant information at each case, such as comments, screen shots, quotes, etc.

This point of view came from my old company, where we used Salesforce as sold out of the box. It wasn’t until I changed jobs that I realized it was so much more then that.

Before we get to that, let us take a second to discuss the typical pros and cons of Salesforce, filtered by my experience.

Pros and Cons of Salesforce

Pros

There is a reason why Salesforce is so popular. The typically stated pros of using Salesforce include:

1. Ease of use
2. No Software (Which comes with its own pros and cons)
3. Flexible and Customizable
4. Outstanding user resources
5. AppExchange

Cons

Of course, it has its share of cons:

1. Slow and lots of screen refreshes
2. Can get expensive
3. Cumbersome customization tools
4. Cumbersome permission system
5. High exit costs

Alternatives

It wouldn’t be fair to talk about the pros and cons of a system without mentioning some alternatives. I will only list them, since I have no experience with any myself. There are plenty of other comparisons out there. Some alternatives include:

• NeonCRM
• SugarCRM
• Microsoft SAP

Developer’s Perspective

We all know Software Engineers are another breed. Most analysis of Salesforce are far too shallow for us. How does the backend, APIs, and developer tools stand?

Lets discuss advantages again, but this time from the eyes of a Software Engineer

Pros

Avoid the Low Level

For many applications, most functionality will be in the front end, the user experience. Installing databases and developing DAO and middleware is done only to support the front end. This is where Salesforce is most appropriate. The database and data management portion is done for you. This lets us concentrate on what really matters.

Flexible and Customizable

Almost all factors of Salesforce are customizable. You can add and remove navigation bars, hide, add or remove new fields to objects, create new objects, create workflows, all without writing code. As a developer, you can take this even further, fully customizing screens by writting HTML, Javascript, VisualForce markup, and Apex. You can take advantage of Bootstrap, React, and other web libraries.

Integrations with other platforms

This feature has become a theme of the Internet 3.0 and the Cloud revolution, in the shape of APIs. Salesforce is an excellent example of this. Several companies have taken advantage of this to come up with software connecting Salesforce with other software and datasets. Of course, we can take advantage of the API to integrate data ourselves. This allows us to get just about any data in to Salesforce. This takes us to the next pro. (Of course, not all data is a suitable fit for Salesforce. I will address this later.)

Central Repository

The ease of exchanging data with other system makes makes a strong case for allowing Salesforce to be your Central Repository for different data. An example of this is having contacts from different systems flow in to Salesforce. We could also bring in company events. We could then build an Intranet, where employees can both find contacts relevant in their work, and to view upcoming Company events.

Being able to not worry about the implementation and management of the Database, and to bring in data from different system, allows us to again concentrate on how to use that data in all sorts of useful ways.

Now I want to discuss the cons of Salesforce from a Software Engineer’s point of view. Whenever possible, I will also offer ways to avoid or mitigate these cons.

Cons

Permissions

Salesforce has permissions for just about everything. Field level permissions, page permissions, object permissions. While theoretically this permits exactly the permission you need, this quickly becomes cumbersome to manage as you have multiple roles and permission sets you’d like to set across multiple users and multiple systems.

While likely this will always be cumbersome, the use of Permission sets helps some. You can set field and page level permissions to the set, and then assign any number of permission sets to any number of users.

Lock In

Developing in Salesforce involves using their proprietary VisualForce and Apex. This means your solution will be Salesforce specific. Should you need to migrate from Salesforce, you’ll have to rewrite all your Apex and Visualforce, which will likely prove significant.

This can be mitigated somewhat by abstraction and by using Javascript frameworks like React on the front end. Check out my blog on Salesforce Development with React and Flux for more details.

Resume Distraction

Developing solutions on Salesforce will of course give you experience using their platform. This is a somewhat less sellable skill then other more popular or open source platforms and technologies, such as Django, React, etc.

Despite this con, I have found myself often turning to Salesforce to quickly come up with solutions. This got me thinking how I might get the advantage of avoiding the low level database setup, as mentioned above, while mitigating what I felt was not the most valuable experience for my resume. The solution is again to only use Salesforce where it brings its advantages, at the data level, and use React or other libraries to work on the front end. Again, refer to my blog on Salesforce with React and Flux for more details.

Very Slow

Salesforce’s database, API, and tools are easy to use. They are by no measures fast, though. In fact, in many of our first approaches to solutions on Salesforce, we got complaints on the speed of the database, as well as the need to refresh pages to update changes.

Once again, this can be mitigated by using React on the front end, communicating with the server only when needed, and doing so without needing to refresh the page.

Development Environment still lacking

Salesforce has a web IDE that can be used for development, the Developers Console. While this is extremely useful to avoid having to use a specific computer for development, and also simplifies collaboration, the tool has plenty of problems. It is slow. It has bugs that often result in odd behavior.

The Force.com IDE is another option that integrates with Eclipse. I have just started using this, so it is possible some of my statements are incorrect. While this is a great idea and often works to make you more efficient, it too has a long way to go before being up to par with other IDE experiences. It doesn’t support code collapsing. Autofilling doesn’t work. Your inability to organize files in to folders makes it very cumbersome to find the files you want.

Unfortunately, I’ve yet to find a satisfying mitigation for this. Right now, I tend to use a mix of the Developers Console and the IDE.

Data Suitability

Salesforce is most appropriate for data that will be used by several people, possibly across multiple applications, and that doesn’t require extremely fast database speeds. It is probably also more appropriate for small size databases. I haven’t explored this limit myself, but might guess that if you are dealing with 100k rows of data or more, you’ll likely want to look elsewhere.

Closing Thoughts

I believe Salesforce is an excellent option for many different problems. I would probably find it hard to justify purchasing specifically to create one application you need. But should Salesforce already be used in your company, I would recommend looking more in to it.

 

I hope you enjoyed this post!

-Steven Ford