Are you doing everything you can to keep your production org in tip-top shape?
Your live Salesforce instance, or your production org, is a critical tool for your business and your customers. Without governance and management, it’s easy to lose or duplicate data, create errors, or cause large, overarching issues for your users. As a way to help your team prevent these types of issues from popping up around your production org, Salesforce created their own version of the Application Lifecycle Management (ALM) framework.
What is Application Lifecycle Management (ALM)?
In order to keep up in today’s market, many organizations find themselves making updates to their software on an almost daily basis. Implementing an ALM framework helps your team maintain organization and outline how you oversee updates and track changes as they move from the planning stage to retirement.
Lots of organizations create versions of the application lifecycle management framework that are specific to their product to help customers use their tool more efficiently. These frameworks typically begin with the addition of a new feature or a request for a change and usually end with pushing the new feature to production and letting end users apply it. The cycle repeats any time updates or changes need to go out.
For Formstack Salesforce app customers, the Salesforce ALM framework can help you safely build forms in your sandbox and feel confident when pushing new forms into production.
What does the Salesforce ALM look like?
The Salesforce Application Lifecycle Management framework includes six steps.
Step 1: Plan Release
Salesforce starts their ALM framework with a planning phase. They suggest you kick things off by gathering requirements for your deployment project and analyzing them. Then, create design specifications and share them with the development team for implementation. To complete this stage, set the development and testing environments your team will use as the project progresses through the cycle.
Step 2: Develop
Next, you’ll start working in an environment containing a copy of the production org’s metadata, but with no production data. Salesforce suggests that you 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, the Force.com IDE, or Visual Studio Code).
Step 3: Test
For step three, it’s time to start testing your changes to make sure everything works as intended before you start the process of integrating with the work done by other team members. Your testing should be done in the same type of environment you used during development. However, you’ll want to keep your development and integrated testing environments separate. At the end of this step, make sure to focus on testing your changes themselves, rather than trying to understand the impact your changes will have on other parts of the release or on the app as a whole.
Step 4: Build Release
Before your second test, take some time to aggregate all the assets you created or modified during the “Develop” stage. These assets will create a single release artifact. A single release artifact is a logical bundle of customizations that you deploy to production. From this point on, you’ll want to primarily focus on what you’re going to release.
Step 5: Test Release
Now, you can test what you’re actually going to deploy using a staging environment that mimics production. You’ll want to make sure that your staging environment includes a realistic amount of representative production data and is connected to all the external systems needed to mimic your production system’s integration points. Run full regression and final performance tests, and perform user-acceptance testing. User acceptance testing is when you allow a small group of experienced users test your release and provide feedback. They may find pain points that your developers couldn’t see.
Step 6: Release
It’s time to send your changes to production! Now, you can start to train your employees, partners, and other users to ensure they understand the changes. If a release has significant user impact, consider creating a separate environment with realistic data for training users.
Why should I use this framework for form building?
There are some clear pitfalls to foregoing the ALM framework of governance and developing your forms inside of your production org. Here’s a few examples of how failing to test changes and updates could impact your Salesforce org:
- Creating an infinite processing loop by adding a workflow rule with an error
- Removing your ability to undo a data modification due to a change in field type
- Preventing users from saving a record due to a logic error in a validation rule
- Confusing users with page layout changes instead of improving their experience
This is why the number one best practice we can give you today is to follow the framework that Salesforce has outlined when you’re adding new forms to your org. You might think that adding a process like this will increase the amount of time it takes you to send things to production. In actuality, this process will increase the efficiency of your team’s form development, add a review process to eliminate errors early, and push your form to production faster!
At Formstack, we’re doing our best to support our Salesforce app customers as they work through the Salesforce Application Lifecycle Management framework. That’s why we’ve developed a Release Management toolkit to help you build forms in your sandboxes with ease. With our Release Management toolkit, you can:
- Develop with confidence. Easily follow the Salesforce ALM process and have confidence in making changes to your production org.
- Migrate forms with ease. Upgrade your sandbox management by migrating forms between sandboxes and production orgs without having to reconnect integrations or connectors.
- Create faster. Complete sandbox refreshes and get back to developing faster.