Advanced Salesforce Release Readiness Strategies

Master the Release Readiness Process

• Become a Treasure Hunter
  • Exploring a new release is like hunting for treasure - you can discover new features that will be a game changer for your organization
  • Benefits:
    • Deliver new functionality your users want without custom code/third-party apps
    • Improve existing customizations by eliminating workarounds or limitations
    • Prevent buildup of “feature debt,” a long list of innovations not being utilized
    • Simplify or enhance customizations in your backlog
  • Pre-Release Orgs are the way to get the earliest possible look at new features in action, usually available 3-4 weeks before the sandbox preview starts
    • Pre-Release sign-ups are announced in the Release Readiness Trailblazers Community
• Explore More Resources
  • For visuals in slide format, see the Release Overview Deck, AKA “ROD”
  • Release-in-a-Box kit, which includes short video demos of features
  • Collection of short demo videos on YouTube or live webcasts and webinars
  • For a spreadsheet view of the contents of release notes, see the Release Matrix
  • There is a module dedicated to each release in the Prepare for Salesforce Releases trail
  • Learn MOAR Trailmix/Quest
• Dive Deeper into the Release Notes - steps:
  1. Complete the must-read list
  2. Drill down by cloud
  3. Explore all relevant products/feature areas
  4. Make sure to view info about add-ons because they sometimes include “freemium” features available with no added cost
• Complete the Must-Read List - these sections in particular:
  • How to Use the Release Notes
  • How and When Do Features Become Available?
  • Support Browsers
  • Release Notes Changes - living document with regular updates and changes
  • Salesforce Overall - typically these items are relevant to all customers, concerning areas such as navigation, list views, and search
    
    
• Major benefits of implementing new features for a major release include:
  • Easily delivering new out-of-the-box functionality
  • Simplify or enhance customizations in your backlog
• The Release Notes is a living document that changes frequently, so it’s a good idea to check for updates regularly in the Release Notes Changes section.

Select and Prioritize Features

• Keep it Simple
  • If you have a few dozen users focused on a handful of core use cases, selecting and prioritizing features will be relatively quick
  • User needs would be trackable using a basic spreadsheet by focusing on features that are auto-enabled or easily configured
  • User communication can be a simple email/short video
• Take it Further
  • If the team is larger, or there are many use cases, or several teams managing Salesforce, then a more complex approach may be warranted
  • Focus on three key principles: Forward plan, Defining roles, responsibilities, and processes, and Using advanced tools
  • Forward Plan - when do we do all this?
    • Start planning early (a couple months before the release hits production orgs) to ensure technical resources you need are available
  • Define Roles, Responsibilities, and Processes - Define clearly who’s doing what. Example roles:
    • Product owner/business functional subject matter expert: has in-depth knowledge of a particular business function or process
    • Salesforce subject matter expert (SME): has deep knowledge of the Salesforce platform and educates the wider team on Salesforce capabilities
    • Technical expert: helps evaluate implementation effort from a technology standpoint, defines and implements technical requirements relating to integrations between Salesforce and other systems, as well as any custom code. Developers commonly assume this role.
• Raise Your Game with Advanced Tools
  • As a first-pass, use the Release Matrix to select relevant features for your organization
  • Release matrix is posted on the Release Readiness Trailblazers Community about a month ahead of deployment to production
  • Filter relevant areas for the clouds they have, then read through the features

• Create a Release Management Object
  • Consider even creating a custom release management object to allow you to categorize features by business impact and implementation effort
  • Object name: New Feature
  • Fields:
    • Feature Area, picklist: group features together to make them easier to manage. Examples: Accounts & Contacts, Email, Automation, Case management
    • Business Impact, picklist: rank feature in terms of high, medium, or low value add for your organization
    • Implementation Effort, picklist: rank the features in terms of time and resource to implement
    • Decision Status, picklist: track you features from initial proposal through to deployment
    • Target deployment date, date: when will this feature be deployed? It may make sense to roll out features in phases based on impact.

Test New Features Before a Release

• Identify Your Testing Approach
  • Make sure you factor in time for testing activities ahead of a Salesforce release deployment, considering two types of resources: people and sandboxes
  • In a simple point-and-click implementation, a single admin may be able to handle testing. If you have code, you need developer expertise.
  • Modifications to the codebase may inadvertently introduce “regressions” (changes that negatively impact existing functionality) so Salesforce Product teams perform rigorous “regression testing”
  • Admins/developers should therefore focus on any new features that impact the end-user experience, such as changes to the user interface, and any custom code you built yourself
• What Types of Testing Are There?
  • Unit Tests: unit tests are key if you have done any kind of custom coding
  • Integration Tests: these apply if you have code interacting with anything not native in your org, for example from third-party services
  • Functional Tests: these verify that features work as defined in your technical requirements. They are carried out by developers or end users. For small projects these are merged with user acceptance testing.
  • User Acceptance Tests (UAT): gives end users the opportunity to accept or reject final feature delivery. Its best to focus on business process that are:
    • High value: critical to the business, and/or
    • High usage: used by most or all users
  • Performance Testing: evaluates how your system responds when large record or operation volumes are being handled
• Raise Your Game with Advanced Tools
  • If you have complex custom code, its best to reach for automated testing tools
  • If you have more than one developer, Salesforce recommends automated tools, regardless of complexity
  • Automation tools execute tests automatically each time your codebase changes to check for any bugs that may have been introduced
  • This kind of test automation is called continuous integration (CI). When you change your source code, the CI tool executes the scripts you’ve written for your unit, integration, functional, and UI tests
    • Example CI tools: Travice CI, Circle CI, Jenkins
    • Best tool to use depends on cost, in-house expertise, test types available, reporting needs/alerting capabilities, compatibility
• Tips and Gotchas
  • Set Up and Manage Sandbox Environments: Reference the Developer Sandboxes and Salesforce CLI module for details
  • Test Data: Reference the Unit Testing on the Lightning Platform module for details
  • Integration Testing
  • API vs UI Testing: use API testing instead of UI testing wherever you can, since changes to the UI in a new release generally means the UI test needs to be updated. Example of a UI test tool is Selenium.
  • Performance Testing: be mindful of system governor limits, consider notifying Salesforce Support before running them
    
    
• User acceptance testing (UAT) cannot be automated
• The purpose of a regression test is to verify that existing code continues to work after modifications

Communicate New Features to Users

• Get Users Engaged
  • Be Concise and to the Point - focus on how users can use new functionality in their day job
• Get Users Excited About New Content
  • Feature Pitch: one or two punchy sentences to explain what a new feature is and “what’s in it for me?” for end users
  • Storytelling Demos: show how a new feature can help with a brief demo
  • Cheat Sheet: give your users an at-a-glance view of what’s new, tailored to their role or main use case
  • Power User Content: invite user committees to put together a short video or one-pager on “Favorite new features”
• Reach Users Through the Right Channels
  • Consider any or all of the following channels:
    • In-App Prompt, Email, Chatter, Lunch and Learn, Internal Release Webinar, On the Job
• Grow and Sustain Business Value
  • New features that aren’t “Quick Wins” or “Low-Hanging Fruit” may require a roadmap and rollout that takes more time. Two objectives for the roadmap:
    • Get Buy-in: more effort may be required to identify requirements, define use cases, and define testing configuration
    • Plan: more moving parts need to be coordinated for more use cases and complex functionality
  • Roadmap should include a few key elements:
    • Business goals for features/feature areas
    • High-level project phases and timeline
    • Key milestones (Ex: budget approval, feature deployment)
    • Key players
      
      
• In-app guidance is the most appropriate channel to explain a new feature to a user in context