Understand What Application Lifecycle Management Is
- Identify customizations that are safe to make directly in the production org.
- Define application lifecycle management.
- Explain why the use of the application lifecycle management process helps teams develop apps faster.
- Change set development
- Org development
- Package development
At a high level, all three development models follow the same ALM process. But the models differ in the way that they let you manage changes to your org. Controlling change is a big deal in software development, and you can choose the development model that best suits your situation if you understand your options.
Let’s follow the journey of a Salesforce professional and his company as their development challenges change over time. Over the course of the story, you learn how each development model meets the needs of different situations. Details on how to use the development models are covered in other modules in this trail.
Meet Calvin, the Salesforce Admin at Zephyrus Relocation Services, Inc.
Calvin Green takes on many technical roles for Zephyrus Relocation Services, a talent-mobility firm in Fairfax, Virginia. One of Calvin’s roles is to customize Salesforce for the company’s small but growing Sales team. Using the Setup interface in their production org, he knocks out an impressive variety of new dashboards and reports.
Calvin developed his skills as a Salesforce admin through Trailhead Military, the Salesforce job training and career accelerator program for military service members, veterans, and spouses.
What’s Safe to Change In Production?
You can safely develop some kinds of new functionality in a production org. Customizations that don’t affect data are safe to create in a production org, such as developing new dashboards, reports, and email templates. However, certain customizations made directly in production can create a mess by deleting data or even worse.
What can happen if you don’t test changes before making them available in production?
- A flow rule accidentally creates an infinite processing loop.
- A change in a field’s type modifies data in ways you can’t undo.
- A logic error in a validation rule prevents you from saving a record.
- Page layout changes confuse people instead of improving their experience.
The safest way to customize your org is to make and test changes using a dedicated environment for development. In fact, some changes must be done in a development environment. For example, you can’t write Apex code directly in a production org.
Move to Change Sets for Safer Customizations
As Zephyrus continues to grow, the demand for Salesforce customizations grows with it. The company adds another staff member to help out. The increasing volume of customization requests includes new flows and page layouts, and Calvin wisely resists making these changes directly in the production org.
To meet its changing business needs, Zephyrus decides to upgrade to Professional Edition. In Professional Edition, Zephyrus can create and test what it needs using declarative (point-and-click) development tools in a separate development environment.
In the change set development model, Calvin and his colleague Ella can manage their application by using declarative tools. They don’t need to use a command-line interface or a version control system to meet the increasing customization needs of the Sales team they support.
With declarative tools, Calvin and Ella can create lots of nifty things that boost the productivity of the Sales team. For example, Calvin uses Lightning App Builder to create a filter that displays a rich text component on an opportunity page when the Amount is at least $1 million.
Apply a Little Order to Chaos
Now that customizations are made by multiple people in multiple environments, Calvin considers how he can manage the downstream impact of even minor changes.
For example, the Contact standard object doesn't have a field for Contact Type. Calvin can easily add that custom field and release the new Contact Type field immediately to all users. But should he?
- Does the new Contact Type field conflict with customizations made by someone else?
- Does the Sales team know how to use the new field or do they need training?
- If the field is required, do any integrations or import processes need updating?
- Where does the field appear? On all page layouts? Which list views? Does it show up in any reports or dashboards?
- Should the field be on the Lead object as well? If so, does the Lead conversion process change?
- Is the field required for integrations with other systems? If so, you might need to change middleware, field mappings, endpoints, and so on.
In the Salesforce Trailblazer Community, other members encourage Calvin to look into the application lifecycle management steps Salesforce recommends for developing new and customized apps.
On the Salesforce Developers website, Calvin learns that ALM defines the process of managing an app’s development, from design to final release. ALM also establishes a framework for making app bug fixes and feature enhancements over time.
Wait, Doesn’t Adding Process Slow Down Development?
In a meeting with Ernesto Rondán, the IT department director, Calvin argues for a move to application lifecycle management. ALM provides them with process and policies that help them build apps smoothly and therefore faster, without breaking things. Apps and tools can vary, but the steps in the ALM cycle apply to any Salesforce development project.
Step 1: Plan Release