After completing this unit, you’ll be able to:
- Understand the importance of impact assessment
- Learn why you need metadata dictionary
- Understand the requirements of a metadata dictionary
- Develop your impact assessment strategy
WHY IMPACT ASSESSMENT
In the ALM Trailhead trail there was a section called “Apply a Little Order to Chaos” which shows why impact assessment is so important. But it can be very difficult to do manually.
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.
Back in 2017, the industry analysts, Forrester highlighted the issue that the more Salesforce gets used and customized, the more difficult it is to stay agile. Here is a link to a summary of the full report https://www.computerweekly.com/feature/Five-ways-to-cut-the-risk-of-Salesforce
It is now 2020 and Salesforce implementations have become increasingly complex as Salesforce has additional products and becomes a more strategic platform inside organizations. The Salesforce@scale problems are only getting worse.
Impact assessment should be a key step in your implementation methodology. Impact analysis can start in the business analysis phase with the requirements and business change. But more typically it is during development when the scope of the different metadata items that are going to be changed is known. The impact assessment often starts by looking at a field level.
For example, a change in the way customer success responds to a customer could touch fields on the account, contact, case and related validation rules and automation. It could also change an email template, apex classes and integrations with external systems.
The key question is what other business processes, and other areas of the business, use any of these metadata items, and what impact will the changes have on them? If the contact field called supportlevel__c that you want to change is also used in a flow, this gives you the ‘what’. And now you need to discover the ‘why’ and the ‘how’?
DESIGNING YOUR IMPACT ASSESSMENT APPROACH
When designing your impact assessment, this is what you should consider:
What points in the delivery cycle do you do the assessment? The earlier you do it, the cheaper it is. Catching it in business and data design is 100x cheaper than in build and 1000x cheaper than in production. However, this means you need to perform rigorous requirements capture and business analysis. You should be doing this! It is the quickest way to drive up user adoption because it ensures you are building what end users really want and need. Is there a final assessment prior to go live?
What level of risk are you prepared to accept? To reduce risk to zero, you may need to perform an unreasonably deep level of impact assessment research. It seems that for most, the approach until now was to change, hope…and wait for the screams. At least the WhereUsed button is now available which will eliminate a ton of surprises!
Are you building a metadata dictionary and documentation approach? The cornerstone of any impact assessment strategy must be a Metadata Dictionary and a formal approach documenting changes as you make them. This dramatically reduces the impact assessment costs because it provides the raw data for any assessment rather than having to collect it for every change.
Does making specific changes affect the impact assessment? Adding a picklist or a field requires a different level of assessment than implementing a new managed package; however, I believe you should be evaluating the impact of a requirement and the related user stories, not metadata changes. You are only adding that new picklist item because the business process has changed – surely there are other implications? Changed validation rules, dashboards and reports, updated help?
What is the sign-off process for the impact assessment? How do you show that you have done the assessment and who signs-off before the next phase of work can start? This may be overkill, and may not be required for some level of changes (see the previous question).
NEXT – Metadata Dictionary