Application Lifecycle Management Basics

Flower icon used to indicate that the content is for Salesforce Classic

Attention, Trailblazer!

Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Salesforce Classic.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain what you can develop in production and when to use a sandbox.
  • Explain the key benefits of application lifecycle management.
  • Assign roles and responsibilities for the development team.
  • Identify the elements of a governance framework.


Salesforce now supports source-driven development through Salesforce DX. Here on Trailhead, you can learn how to drive modular-based development with Salesforce DX tooling and how to use the Salesforce command-line interface to create, convert, and deploy your apps.

This module is designed for org-based change management.

Application Lifecycle Management

If you’ve done some of the challenges in Trailhead already, you know it’s easy to build and customize apps. For example, the Contact standard object doesn't have a field for Contact Type. You could easily add that custom field in your production org and make the Contact Type field immediately available to all users. But should you?

Asking this question prompts additional questions. For example:
  • Will your users know how to use the new field, or will training be needed?
  • If the field is required, are there any integrations or import processes which require updating?
  • Should the field appear on all page layouts, list views, or in any reports or dashboards?
  • Should the field be on the Lead object as well, and if so, does the Lead conversion process require updating?
  • Will this field be required for integrations with other systems? This action might require changes to middleware, field mappings, endpoints, and so on.

Non-configuration changes, such as creating views, reports, and dashboards, can be made safely in production. But other changes, such as this hypothetical new Contact Type field, are potential pitfalls of confusion and productivity. Understanding the downstream impact of a change, whether it’s preparing for a new user experience or updating an existing integration, are vital steps to minimize disruption and increase feature adoption. But how do you know when to make a change in production versus using sandbox (a separate environment for development and testing)?

The answer depends on your change management strategy. Some companies need the flexibility to make emergency changes in an ad hoc fashion, rather than as part of a scheduled upgrade. Other companies find this disruptive to users, administrators, and developers and opt to roll out their changes with a formalized release process. And some companies do a mixture of both.

In this unit, you learn about the effects of making changes in production, and why at some point you need to separate development from production using a sandbox. You learn what kind of challenges occur in a multi-org environment, and how to create a development strategy to manage those changes.


This module does not apply to those creating managed packages for the AppExchange. That development scenario has different best practices.

This Trailhead module is different from the Change Management module. Here’s how they're different: If your use cases are simple and you are comfortable with change sets, you might prefer the Change Management module. If you have more complex needs, are an enterprise customer, or need more robust functionality than change sets provide, you might prefer this module. When in doubt, get both badges and decide for yourself!

What Is Application Lifecycle Management?

Application lifecycle management is the process of managing an app’s development, from design to final release, and establishing a framework for managing changes. The typical application lifecycle starts with the design of a new app or feature. The app is planned based on requirements analysis and specifications. Next, the app is implemented per the specifications and then tested. The new app is staged for final testing before it gets deployed to production. This cycle repeats for every new app or feature. It’s also used for app maintenance, such as when features are enhanced or bugs are fixed. A governance and change management framework directs the development process.

Salesforce Application Lifecycle Management
Salesforce application lifecycle management
Step 1: Plan
An app starts with planning. This step includes requirements gathering and analysis. The product manager creates design specifications and shares them with the development team for implementation.
Step 2: Build
Administrators and software engineers write the app per the design specifications. The development is done on the Salesforce platform using declarative tools—the tools available in the user interface—and programmatic tools, such as Apex, Visualforce, and Lightning Components.
Step 3: Test
The app is tested to verify that the changes behave as expected and don’t cause undesired side-effects. The quality assurance team first performs unit and functional testing. A small set of experienced people then provide feedback (user acceptance testing). Staging the changes enables final testing before deploying to production.


In Salesforce, development and test environments are represented by sandboxes. A sandbox is essentially a clone of your production org—its features, functionality, user licenses, and setup configuration. Sandboxes are usually used for development, testing, training, and merging changes from other sandboxes.

Step 4: Deploy
When testing is successfully completed and the quality benchmarks have been met, the app can be deployed to production. The release manager manages releases to production. Training employees and partners about the changes is a best practice.

Development Lifecycle Roles

In a smaller company, one person can wear many hats, but in a larger company, specialized roles define what each person is responsible for. Logical roles include the following.
  • Release manager—Manages the release schedule and coordinates releases with the business. The release manager could be in charge of pulling changes from version control.
  • Product manager—Provides the business requirements of apps and features, and works with the development team to implement those requirements. The product manager also performs user acceptance testing to ensure that requirements have been implemented.
  • Software developer—Develops new functionality in sandbox, including both declarative point-and-click development and code.
  • Quality engineer—Tests new functionality in sandbox.
  • Administrator—Performs administrative tasks in the production org, and tracks all changes made in production.
  • Trainer—Conducts training of company employees for new applications and features.

Use Governance to Manage Change

You’ve learned how to keep your organization lean and clean using the tools that Salesforce provides. However, governance, a method of management, is about more than tools. Governance improves agility by ensuring all members of your team are working together to achieve goals that are aligned with overall business goals.

word cloud of governance words

Three elements of a responsive, adaptable framework for governance are:

Center of Excellence
A few stakeholders from different functional groups work together to ensure that changes support business goals and follow IT best practices and processes.
Release Management
You’ve already learned how to use tools like change sets and a sandbox to manage changes. If you use a backlog list to manage priorities, you can work on the most important changes first. And if you design and document a complete release management process as you learn more about your organization, everyone who works with Salesforce will be able to know how to do so safely.
Design Standards
Follow key standards for coding, testing, integration, large data volumes, and other areas that affect the services you share with other Salesforce customers.

Create a Release Management Process

By using sandbox and permission sets, you’ve already created a simple release management process. Add structure by setting up a release schedule and defining criteria for major versus minor releases.

Releases typically fall into one of the following categories:
Bug fixes and simple changes that do not require formal release management, including reports, dashboards, list views, email templates, and user administration.
Changes with limited impact, such as a new workflow rule or trigger impacting a single business process. These releases typically require testing, but limited training and change management, and are delivered within a few weeks.
Changes with significant impact, including configuration and code changes with one or more dependencies. Because these releases greatly affect the user experience and data quality, they require thorough testing, training, and careful change management. Major releases typically occur once a quarter (or like Salesforce, three times a year). Releasing on the same day of the week for minor and major releases is a best practice. This allows for company-wide planning and sets expectations with your business users. In addition, don’t schedule releases near holidays or other major events.
Your release management strategy evolves over time. Add checks and balances as you discover frequent points of failure or common root causes. The CoE shares these best practices so that everyone who modifies or extends Salesforce knows how to do so safely.

Design Standards

Salesforce is configurable, extendable, and supports integration with other applications and services. By following the same design standards, anyone who modifies your organization can ensure that their changes aren’t in conflict with another group’s changes. In addition, with Salesforce’s multi-tenant architecture, employing design standards helps ensure your changes stay within set governor limits.

Some examples of design standards include:

  • Standard naming conventions
  • Consistently using the Description field
  • Bulkified code
  • Standard methods for deprecating classes and fields
  • Consistent data architecture across all projects
It’s important to have design standards for the following areas:
  • Coding
  • Testing
  • Integration
  • Handling large data volumes
  • Documentation

The architect or architecture team in your center of excellence defines your company’s design standards. Publish your design standards, and communicate them to all teams that work on Salesforce projects, and the rest of IT.

Development Lifecycle Environments

Let’s take a look at how to implement a software development cycle in Salesforce, starting with an easy example using a single development and testing environment. Each development and testing environment is represented in Salesforce by a sandbox. You learn more about sandboxes in a later unit.

Single Development and Test Environment

For small or quick projects, it’s possible to simplify the development lifecycle by using a single environment for development and testing. If you’re just getting started developing in a sandbox, using a single environment is a good way to begin.

Typical code migration path.

This simple development scenario is suitable for small and fast projects, such as:
  • New custom objects, tabs, and applications
  • Integrations with other systems
  • Apps involving Visualforce, workflow, or new validation rules

Multiple Development and Test Environments

As your development process matures, you’ll find that having multiple sandboxes allows greater flexibility. Even adding a single sandbox for testing frees up the developer sandbox for new features while testing proceeds.

Typical code migration path.

This scenario starts to show its limitations when you have more than one developer working in the sandbox. In short, you can count on conflicts and overwriting changes. In this case, it can be better to have each developer work in their own Developer Edition org and deploy to the sandbox as a means of integration.

When you have multiple developers in multiple sandboxes, you need to merge changes between the sandboxes before you deploy, which requires an integration sandbox. As you add more sandboxes to separate development projects, testing, and deployment, the picture becomes more complete. This next diagram shows the environments used for a development project slightly more complex than the previous one. The team has two developers, each with a sandbox. The changes from the developers are merged into a single testing environment (QA). After testing is completed, the changes are pushed to an environment where staff other than engineers can perform user acceptance testing (UAT). For example, product managers can use the UAT environment to ensure that the features work as expected and demo them. Finally, to ensure a smooth release to production, the changes are first staged in the staging environment and then released.

Typical code migration path.

Alternatively, changes from multiple developers can be merged in an external source control system. The source control system hosts the metadata (which includes source code) of projects in development in separate branches. When the app is deployed to production, it’s deployed from the source control system. The following diagram shows a comprehensive release cycle with all the intermediate development, testing, and staging environments. This release cycle uses a source control system.

Use a Central Source Control Repository with Multiple Environments

Use a source control repository, such as git, for team development. Using an external source control repository enables merging changes from multiple developers. Also, the repository allows isolation of projects that are in development. The source control repository is the source for all customizations deployed to all other environments. After the changes have been tested and validated in the various environments, a test deployment is made to the staging environment. If the deployment succeeds, the changes are migrated to production. This next diagram shows the various environments used in a team development project. The diagram is broken up in the different phases of the development lifecycle for releasing an app.

Full application lifecycle diagram for feature releases