One thing that I have learned during my time as an admin is that being organized, knowing what has changed when and the impacts those changes might have to the Salesforce org are some of the most important things to have processes and procedures around.
To me, release Management is an all-encompassing topic including agile style sprint planning, tracking of future projects and backlogged items, QA/test plans, and release notes. For Salesforce, I see these broad, typically engineering concepts, having specific and useful definitions and purpose. One of the reasons, I think that this is so important is that I have seen first hand what happens when you don’t have these items in place and the negative downstream impacts it can have.
Before jumping into sprint planning, let me call out something that should not be skipped over.
Dev Org Structure
For each Production SFDC instance you have, you should have a minimum of 3 orgs:
- A Dev Org – where any and all development work is done before reaching production
- A Full or Partial Sandbox – this is where any dev work should be tested so it is in an environment most closely representing Production
- A Production Org – I think this is pretty straightforward, but I will note, NO dev work should ever be done here
The reason this structure is important is two-fold. First, it allows you to maintain a specific environment for each type of activity that will be done in that org. Second, this will prevent any mishaps in the Production org. I have seen what happens when a rapid-fire decision is made without testing and is immediately put into Production, let’s just say you want to avoid this.
Once you have your structure setup, you can start thinking about structuring your planning schedule. This is a critical part of release management, as it allows for those working directly on SFDC and those being indirectly impacted to have a consistent idea of what to expect when.
A quick definition for those of you who may not have been exposed to Agile before. This is basically a planning style that allows you to have set dates of when development work will happen and when pushes will happen, while still allowing the business to be in a growth state and be flexible. The idea behind Agile is that you can easily make a change in the work that needs to be completed without having to re-adjust any major timelines.
So for sprint style planning, personally, I think a tool like JIRA or Task Ray (if you want to remain in SFDC) are an utmost key to having this type of agility planning. These tools allow you to create tags based on different projects, create views for different owners, see tasks within a specific timeline and most importantly, allow you to visualize (see Kanban) where all of your tasks/projects currently sit. Once you have a tool like this, you can set up a release schedule – timing is completely dependent on your organization. The schedule should include when development work will be, and when pushed to test and prod will be, and when QA will happen.
Once your schedule is in place and your tickets/tasks all squared away into their happy places you can think about test plans and release notes. Typically the way I like to handle these two items is through good documentation and using simple tables. For test plans, I always make sure to note what change made, what steps should be taken to test it, and what the expected results for each test case should be. On instances where the change is for a specific role or profile or use, I will also add a user type or profile column, to ensure that the change has accounted for specific types of impacts – think validation rules based on a profile.
I handle release notes very similar to the test plans. I will create them at the end of each Dev cycle and encompass all changes that have been made, as well as any changes to user behavior that has occurred. I also like to do this in a table format. I find that everything should be in a place that is readily accessible at any time, like a Wiki, however, I also send out a copy via email the same day changes are pushed to Production so that people know what they should be expecting in the release.
I believe that if you follow guidelines like the ones I have laid out above, you will be following general best practices both for Salesforce and for Agile development. This process will be able to give you, your coworkers, and end users peace of mind. End users will be able to easily know when to request changes and when to generally expect changes to appear in Production. Your coworkers will be able to quickly location answers using the release notes as reference points in the future. And, if a new admin joins, there will be good documentation available for them to get up to speed on the current state of affairs.
About the Author: Yelena is a 1x certified Salesforce Admin. She currently works for a small startup in Silicon Valley as both a project manager and as their sole Salesforce Admin. In her free time, she likes to work on her own blog – sf9to5.com – as well as working on her side art career. She hopes to someday have additional Salesforce certifications and work her way up to becoming a Salesforce Business Architect.