Salesforce solves many business problems for companies from the SMB to the Enterprise and is flexible enough to be configured in nearly infinite ways to solve many issues, but by no means can Salesforce do everything for everyone. At CodeScience, we work with companies who offer solutions that enhance, augment, or fill the platform’s white space.

When we talk to those who are new to the ecosystem and evaluating their opportunity to bring their solution to hundreds of thousands of potential customers, we often find that these companies forget that their customers are developing on their own instance of Salesforce as well. We think it is important for those building on the AppExchange to have the fundamental knowledge of how their customers use Salesforce and develop in conjunction with their applications.

What is Application Lifecycle Management?

We’ve previously discussed the AppExchange Product Lifecycle — the series of stages every app and Lightning component goes through before they go live and start generating revenue.

Application Lifecycle Management (ALM) on the other hand, is the way a Salesforce owner or admin rolls out changes and enhancements to their Salesforce instance (otherwise known as an org). Having a solid ALM process ensures the org continues to work properly and delivers the most value to end-users.

One important thing to know is within the ALM process there are three separate development models: change set development, org development, and package development. While they all still follow the same ALM steps, they are different in the ways they let Salesforce owners and admins roll out and deploy changes to their orgs.

Change Set Development

Change set development provides companies with a development environment that’s entirely separate from their production environment. This gives companies a safe way to test changes that may affect data and their users’ experience.

For example, while it would be okay to test out a new report in production, you would never want to roll out a new workflow rule without testing it. If the workflow rule caused something negative to happen, this could cause confusion and errors for end-users who are currently using the system. It’s best to try out changes in a safe sandbox environment before rolling them out in production.

Org Development

While change set development works perfectly for many companies, if an organization has many changes to manage or simultaneous, complex testing going on, they may consider choosing, or moving to, the org development model. Org development offers a few advantages over change set development, including eliminating the requirement to manually keep track of changes you’re testing out in each sandbox.

Additionally, org development offers some automation options that change set development does not, and it can keep multiple environments in sync by using a source control repository, sometimes called a source repo. Overall, it can streamline change management and boost productivity.

Package Development

If a company has many different projects that each have their own needs, they should consider moving to package development. Package development offers the most flexibility and can handle the most complex organizational structures. With package development, you can manage changes as separate packages, instead of viewing them as one big set of changes for each release.

The package development model relies on metadata to make updates within your org and allows you to track changes within your organization’s metadata. Thinking of your organization in terms of packages and then planning around them can help you with complex change management processes, improve collaboration between teams assigned to various packages, and more.

Why This is Important for ISV Partners

It can be easy for ISV partners building on the AppExchange for the first time to forget that their customers are continually developing on Salesforce as well. SMBs to Enterprise organizations will adopt any combination of these development models depending on their size, complexity of the task, and budget.

As your customers roll out changes, you must be ready to support them if their changes cause impacts to your application. Often, your customer will see this as an issue with your app rather than an issue with their org — and being able to diagnose where these issues were introduced is paramount to great customer success and client retention.

While all ISVs hope that their customers adopt good change management and follow quality ALM best practices, we know that isn’t always the case. It can be hard to diagnose where these issues were introduced and even harder to uncover if it is your app, their recent release, or another app entirely causing issues in their org. We have an elite team of developers who specialize in solving these issues, which make up a portion of our Commercial Services offering.

CodeScience helps organizations build businesses on the Salesforce AppExchange. From ideation, architecture, and beyond, we’ve built over 250 commercial-grade products and know the ins, outs, and gotchas of the ecosystem. Don’t navigate this process alone. Get in touch today!