Building an App on Salesforce? Here's What you Need to Know

Salesforce, as an app development platform, can be a phenomenal way to rapidly go from idea to go live. A low-code environment, an active community of devs, and flexible options for development and testing are a few of the reasons the platform is consistently chosen to develop on.

But, there are some very unique things about building on Salesforce that you should understand before jumping in that will make your experience (and life) much easier. Most of these things we learned the hard way at some point in our careers. So let our former pain and suffering be your guide!

Special note - Listing on AppExchange

If you are building an application to list on AppExchange, there is another set of considerations to make. We have an overview for you here.

1. You need to clearly define the problems

Solutions serve no purpose without a problem to solve. That probably seems obvious. But, many of us have seen (or been part of) development efforts that seem to be nebulous solutions in search of a problem that leaves everyone asking, “why?”

Having clear problem definitions gives everyone involved something to reference back to and guide efforts. Most importantly, though, is making sure these are actually listed and understood by everyone. Otherwise, you will run into a situation where one person thinks we are working toward something and another person believes something else, leading to conflicts, reworks, and headaches for everyone.

So write it down, talk about it, put it on a billboard - whatever makes sense to make sure the team understands and is bought-in on what problems are being addressed.

2. Decide what licenses you want your app to use

Salesforce has, to put it mildly - a lot of different licenses to choose from. When it comes to the core “Platform” license most commonly used for app development, it gets much more narrow, with two options to choose from depending on the scope and requirements of the app you are building.

If you are considering building on-top of other licenses, such as Sales or Service Cloud, you should understand the different capabilities that each level of license can provide to you. Sometimes, this requires a bit of understanding of how your application will be architected -  since many of the capabilities you gain revolve around usage and limits, such as data storage and field creation limits.

Don’t pay for more than you need, but make sure you understand the trade-offs you are making by selecting a less expensive license.

3. Know your (technical) limits

Building on Salesforce introduces some very specific limits that must be considered and understood to avoid developing yourself into a hole.

For example, you should understand the basic limitations of object and field creation. For example, the number of fields you can have per custom object can have a high degree of variability depending on the particular type of license being used.

Other limits are critical to understand to make sure you are designing the right architecture. Data storage limits, API limits, and if you are using custom code, a whole other set of governor limitss to understand.

“Seriously - don't code what you don't have to. You will make everybody's life easier.”

decorative picture of computer sceen

4. Understand the uses of different sandboxes (and make sure your team does, too)

Unless you are pure chaos and building in production, your work will be taking place in some kind of sandbox or development org. There are some really interesting differences that make each one a good fit for different use cases.

First, the full sandbox. This is a complete copy of a production org, with all data included. This is extremely useful for final testing and QA since you know you are working with a one-to-one copy of production. Full sandboxes for Salesforce also support things like load testing, performance testing, and staging. They can only be refreshed every 30 days, and you will probably be limited in the number you can maintain. You can always pay for more, but often the business need can be satisfied by a different type of sandbox or testing environment.

Partial sandboxes are clones of your org, but with only a slice of the actual data. You can choose what data you want to apply by using templates, and you can have several templates to use for different sandbox needs. They can also be refreshed every 7 days, and you will probably have access to a much, much larger number of partial sandboxes than full sandboxes.

Developer sandboxes (and Developer Pro Sandboxes) are clones of your org, but only with your configuration and metadata customizations. These are often the workhorse of day-to-day development work and are especially useful for things like integration testing.

Another type of org, although technically a sandbox, that should be mentioned here are Scratch orgs. Scratch orgs aren’t clones of any production instance, but can have any type of configuration applied to them. These are basically disposable Salesforce instances, and they expire after 30 days (Seven days is the default expiration time - don’t forget to change it if you want longer). Scratch orgs are especially useful of your app will be used in Salesforce orgs of different metadata configurations. This gives you a much more robust testing option, particularly if your app is going to be sold/distributed externally.

5. Don’t code what you don’t have to

The declarative configuration and development capabilities the Salesforce platform provides can be a boon to development speed and simplicity. Even better, it makes understanding how something was built (and changing later if needed) much easier from person-to-person.

Sometimes, we as devs think that we can just solve any use case with code. That’s probably mostly true - but there are some really good reasons to avoid custom code. Namely, how easy it is for anyone to immediately understand how something was built and configured. Anyone who has had to read through someone else’s code knows the feeling. The “what the hell?” moment where you realize it’s going to take a ton of time to unravel.

Not every use case can be solved without code, and even though low-code options have completely exploded, that’s probably always going to be true. But, with Salesforce, you should embrace a mentality of only using custom code when it is truly necessary.

These are just starting to scratch the surface. The world of Salesforce development goes wide and deep. Our final piece of advice to get started would be to dive into the community of devs and configurators - both in the official Salesforce community and in various Discord servers. There is tons of expertise out there, and you know, people just love to tell you when you are doing something wrong.