Application Lifecycle Management (ALM)

Application lifecycle management provides a framework for software development while also helping you to manage your software over time.

Application Lifecycle Management (ALM) is the specification, design, development, and testing of a software application. ALM covers the entire lifecycle from the idea conception, through to the development, testing, deployment, support, and ultimately retirement of systems.

Step 1: Plan Release

Start your customization or development project with a plan. Gather requirements and analyze them. Have your product manager (or equivalent) create design specifications and share them with the development team for implementation. Determine the various development and testing environments the team needs as the project progresses through the ALM cycle.

Step 2: Develop

Complete the work, following the design specifications. Perform the work in an environment containing a copy of the production org’s metadata, but with no production data. Develop on Lightning Platform using an appropriate combination of declarative tools (Process Builder, the Custom Object wizard, and others in the UI) and programmatic tools (Developer Console, Source Code Editor, or Visual Studio Code).

Step 3: Test

Exercise the changes you’re making to check that they work as intended before you integrate them with other people’s work. Do your testing in the same type of environment as you used in the develop step, but keep your development and integrated testing environments separate. At this point, focus on testing your changes themselves, not on understanding how your changes affect other parts of the release or the app as a whole.

Step 4: Build Release

Aggregate all the assets you created or modified during the develop stage into a single release artifact: a logical bundle of customizations that you deploy to production. From this point on, focus on what you’re going to release, not on the contributions of individuals.

Step 5: Test Release

Test what you’re actually going to deploy, but test safely in a staging environment that mimics production as much as possible. Use a realistic amount of representative production data. Connect your test environments with all the external systems they need to mimic your production system’s integration points. Run full regression and final performance tests in this step. Test the release with a small set of experienced people who provide feedback (a technique called user-acceptance testing).

Step 6: Release

When you’ve completed your testing and met your quality benchmarks, you can deploy the customization to production. Train your employees and partners so they understand the changes. If a release has significant user impact, create a separate environment with realistic data for training users.

Release Management Process

Releases typically fall into one of three categories.

Patch

Bug fixes and simple changes. Simple changes include reports, dashboards, list views, and email templates. This is also a kind of hotfix.

Minor

Changes with limited impact, such as a new workflow rule or trigger impacting a single business process. These releases typically require testing, but only limited training and change management. Typically, a team delivers the changes for a minor release within a few weeks.

Major

Changes with significant impact, including changes with one or more dependencies. Because these releases can greatly affect the user experience and data quality, they require thorough testing, training, and careful change management. Major releases are typically delivered once a quarter (Salesforce does it three times a year).

Deployment Models

There are three development models.

1. Change set development

2. Org development

3. Package development

Change set development

• It's a declarative tool to deploy the changes from one org to other org using Inbound and outbound change set

• The outbound changeset is created on Source org and the Inbound change set created in target org.

• Both the org should be connected org

• The change set is good when you have less complex deployment. Refer to my previous blog to know more about change sets.

Org development

• Change set is good when your org is pretty much small and development is not going frequently.

• Let's consider that you have  an org where you have multiple teams working together. Change set will not be a good approach for this. You can use an org development model.

• Org development model that uses some different tools that provide

• greater flexibility and scalability

• new ways to track and manage change

• a different method of deployment.

• Org Development Model Manage change with Salesforce DX tools and source control.

Salesforce DX 

• Salesforce Developer Experience (DX) is a new way to manage and develop apps on the Lightning Platform across their entire life cycle. It brings together the best of the Lightning Platform to enable source-driven development, team collaboration with governance, and new levels of agility for custom app development on Salesforce.

• 

Salesforce DX Project

The Salesforce DX project contains the source and files that comprise your changes. A DX project has a specific project structure and source format.

• In addition to source files, the project contains a configuration file, sfdx-project.json. This file contains project information and enables you to leverage Salesforce DX tools for many of your development tasks.

• You can think of the DX project as your outbound change set, where you’re managing and collecting the changes that you want to send to your production org.

• A DX project has this structure:

Deployment Artifact (.zip File)

After testing the changes, Juan creates the deployment artifact, a .zip file that contains changes to deploy. He deploys the release artifact to the Full (staging) sandbox first, and then finally to production. You can think of the deployment artifact as the inbound change set. The changes don’t take effect until they are deployed.

Source Control System

All changes are merged and stored in a source control system, which contains the Salesforce DX project. A source control system provides several benefits.

• Real-time collaboration increases efficiency and drives consensus.

• The team can work on the same files at the same time without fear of overwriting changes or losing work.

• Revision history shows who made which changes.

• You can revert to earlier versions of any file. It’s like having your very own time machine where you can go back and save the universe from destruction.

• When you save work you provide a commit description, which provides historical context for the work.

Salesforce CLI

Salesforce CLI is a powerful command-line interface that you can use for every phase of the org development lifecycle. It improves productivity by providing a single interface for all your development, test, and automation use cases. You can:

• Authorize sandboxes (headless or web flow)

• Create and manage DX projects

• Import and export test data

• Retrieve and deploy metadata

• Run and automate tests

Salesforce Extensions for Visual Studio (VS) Code

Salesforce Extensions for VS Code is built on top of Salesforce CLI and VS Code. Together, they are an integrated development environment that’s created for custom development on Lightning Platform. Best of all, you can run Salesforce CLI commands directly from the command palette or terminal. The development team installs the Salesforce Extension Pack so they can use these VS Code extensions:

• Salesforce CLI Integration—interacts with Salesforce CLI to provide core functionality.

• Apex—uses the Apex Language Server to provide features such as syntax highlighting and code completion.

• Apex Replay Debugger—enables VS Code to replay Apex execution from Apex debug logs.

• Aura Components—supports Aura component bundles.

• Visualforce—supports Visualforce pages and components.

Package development (Unlocked Package)

• Packing is the other way to deploy the component to another org.Packaging allows you to group various Salesforce Components for distribution or deployment. 

• A package can also be defined as a container and allows for deployment of the components across various Salesforce organizations. Salesforce Set up UI and Salesforce CLI allows for creation of these. Package Creation yields a URL that allows it to install in various orgs

• Salesforce offers different types of packages 

• Unmanaged

• Managed 

• Unlocked

• Unlocked packages are especially suited for internal business apps and allowed you to do modular application development. Unlocked package is the right package type for most use cases, Unless you plan to distribute an app on AppExchange. You can use unlocked packages to organize your existing metadata, package an app, extend an app that you’ve purchased from AppExchange, or package new metadata.

• Unlocked packages help you add, edit, and remove metadata in your org in a trackable way. You can install unlocked packages to multiple orgs, and upgrade your Salesforce apps easier and faster. Metadata in unlocked packages can be modified in a production org ( You can do in case of emergency but not recommended).

Unlocked packages follow a source-driven development model. The source of truth of the metadata contained within the package is your version control system, not what’s in an org. This model brings with it all the advantages of modern source-driven development models.

UNMANAGED PACKAGE, MANAGE & UNLOCKED PACKAGE

Unmanaged Package	Managed Package	Unlocked Package
Package is not upgradable	Upgradable and has namespace	Upgradable and one can namespace them or choose not to
Metadata elements are not IP Protected	Metadata elements are IP Protected	Metadata elements are not locked and can be changed by system admins
Can we created in Salesforce UI	Can be created in salesforce UI and distributed via appexchange	Requires Salesforce CLI to generate them
Unmanaged package containers automatically pull dependency	Components are locked and one cannot modify them directly in production or sandbox	Allows you to build your applications in a modular way

Lightning Flow

Lightning Flow is a product that provides a declarative automation process. Lightning flow products use two tools that let you build flows.

• Process Builder (Use Process Builder to make processes)

• Flow Builder (Use Flow Builder to make flows)

Flow Builder

Flow Builder is the declarative interface that we use to build individual flows. Flow Builder can be used to build code-like logic without the requirement of knowing a programming language.

Use Flow Builder to:

• Automate a guided visual experience.

• Add more functionality for a behind-the-scenes process than is available in Process Builder. Use Flow Builder to build more complex functionality. Then call the resulting flow from the process.

• Start a behind-the-scenes business process when a user clicks something, like a button.

Flows in Salesforce can be implemented in two ways:

• Screen Flows

• Auto Launched Flow

What is a Flow Interview in Salesforce?

A flow interview is a running instance of a flow. Flow is an application built by your administrator that asks you for inputs and does something in Salesforce based on those inputs.

For example, a flow could provide a call script for customer support calls and use the information you provide to create a case. What the flow does with the information you provide is entirely up to your administrator.

When you run a flow interview, whether, through a link, button, or tab, you're running a single instance of a flow. If the terminology is confusing, consider the difference between a record and an object. You create an account record, which is a single instance of the Account object that your administrator customized.

Process Builder

Process Builder helps you automate your business processes and gives you a graphical representation as you build it. Process Builder is the enhancement of the workflow. 

Process Builder supports three types of processes for your automation needs. The type determines what triggers the process.

• A record change process starts when a record is created or updated.

• An event process starts when a platform event message is received.

• An invocable process starts when something else, like another process, invokes it.

Each process consists of:

• Criteria that determine when to execute an action group.

• Action groups, which consist of immediate or scheduled actions. Only record change processes support scheduled actions.

Process Builder vs. Workflow

Use the more powerful and flexible Process Builder to perform the same actions as Workflow. With Process Builder, you can:

• Create a record of any object type

• Update any related record—not just the record or its parent

• Use a quick action to create a record, update a record, or log a call

• Invoke a process from another process

• Launch a flow—you can’t schedule this action with workflow

• Send an email

• Send a custom notification

• Post to Chatter

• Submit a record for approval

If you need your process to do more than what process actions allow, don’t worry. You can also call Apex or flow from a process.

Action supported by Process Builder

1. Apex (Apex class should have InvocableMethod method)

2. Create a Record

3. Email Alerts

4. Flow

5. Post to Chatter

6. Processes

7. Quick Actions

8. Quip (Quip is real-time collaborative documents, spreadsheets, and chat embedded inside Salesforce to transform any business process.)

9. Send Custom Notification

10. Submit for approval

11. Update Records

Flows Builder vs Process Builder

Flows and Process Builders are similar. Here are some of the key differences and similarities between the two:

 

Process Flow	Process Builder
Flows allow you to add screens where users can enter data	Process Builders do not have this capability
Flows can be Auto-Launched or started by users.	Process Builders run automatically (either immediately or scheduled) when criteria is met.
Flows can have different and more complex orders of operations.	Process Builder actions are executed in the order in which they appear in the process definition.
Flows can be built to cycle through multiple un-related and related objects.	Process Builders are limited to the base object (i.e Opportunities) and related objects (Accounts).
Flows can be paused by users,	Process Builders run when the criteria is met and cannot be paused.
Process Builder is more user-friendly in terms of its setup and management.	Setting up a flow takes more time and significantly more complex.
Flow don’t invoke process builder	Process builder can invoke flow directly
Can delete the record	Does Not support deletion of records

Quip

• Quip is a smarter cloud-based collaboration platform. Teams create, discuss, and get work done faster from any device with content and communication combined in a new way. 

• Quip can be called from Flow or process builder and can perform below operations.

Salesforce Licenses

• To enable specific Salesforce functionality for your users, you must choose one user license for each user.

• When creating or editing a Salesforce User, there is a picklist field that lets you assign a specific User License. 

• Salesforce License is like a driving license. If you want to drive the vehicle, you must have a License for that particular vehicle. Let’s say, if you want to drive a car, you must have a 4 wheeler car licence. Also, if you want to drive a bike, you must have a two wheeler license. Same way, you have different types of salesforce licenses depending on your needs.

• You can check Licenses details can using Setup-> Company Information

Types of Licenses

Salesforce provides the following types of licenses and usage-based entitlements.

1. User Licenses

2. Permission Set Licenses

3. Feature Licenses Overview

4. Usage-Based Entitlements

User Licenses

A user license determines the baseline of features that the user can access. Every user must have exactly one user license. You assign user permissions for data access through a profile and optionally one or more permission sets. User License determines which kind of profile can be assigned to a user.

You can check from Company Information or use query to retrieve the UserLicense

SELECT MasterLabel,Name,Status,TotalLicenses,UsedLicenses,UsedLicensesLastUpdated FROM UserLicense

There are different types of User License as below

• Standard User Licenses

• Salesforce

• Salesforce Platform

• Salesforce Platform Light

• Force.com-One App

• Force.com-Free

• Idea & Answer Internal User

• Contact Only User

• Knowledge Only User

• Chatter User Licenses- Users that have a Standard Salesforce License have free access to Chatter. For other users, Salesforce offers Chatter-specific licenses.

• Chatter Free

• Chatter Only - The Chatter Only license is available for purchase only by existing Chatter Plus customers. For new customers, the Lightning Platform Starter license is a step up from Chatter Only, giving your users access to a more robust set of features.

• Chatter External

• Communities User Licenses- Salesforce communities can be a huge boost for any business because it allows you to connect with your partners, customers and internal team in a curated and functional way. You can connect your Salesforce org, define exactly what data will be shown to users of the community and custom tailor it to your use case, sales, customer support, knowledge bases, you name it. There are actually 6 different licenses for external community users:

• Customer Community

• Customer Community Plus

• Partner Community

• Commerce Portals

• External Apps

• Channel Account.

Permission Set Licenses

• Permission set license is used to assign permissions to use various tools and functions which are not included in User License.

• You can find all PSL from Company page or from below SOQL query:

SELECT MasterLabel, ExpirationDate,TotalLicenses, UsedLicenses FROM PermissionSetLicense

• We can use permission set licenses to grant access, but not to deny access.

• Users can be assigned any number of permission set licenses.               

• Einstein Analytics Plus

• Event Monitoring Analytics Apps

• Health Cloud Platform

• Einstein Agent

• Einstein Search

• Einstein Analytics Plus

Feature Licenses

• A feature license entitles a user to access an additional feature that is not part of a user license, such as Marketing or Service Cloud User. Users can be assigned any number of feature licenses.

• The feature provides the ability to specify additional add-on functionality that can be supported in the edition. Features generally enabled add-on license in the org and things that a user cannot enable themselves in the org via setup.

• You can see all feature licenses from company information also if you want to get a feature license from the apex, there is no object which exposes these details. As these features are added to users, so we can use User objects to find most of the features count.

• Example- Find out Users having  “Marketing User”

Select count() From User where UserPermissionsMarketingUser=true and isActive=true

Usage-Based Entitlements

• A usage-based entitlement is a limited resource that your organization can use on a periodic basis. For example, the allowed number of monthly logins to a Partner Community or the record limit for Data.com list users are usage-based entitlements.

• Company A purchases 50 monthly logins for a Partner Community, and on January 15 that org has a pool of 50 logins. Each time someone logs in, one login is used. On February 15, no matter how many were used in the previous month, the pool is refreshed and 50 logins are available through March 14.