5 minute read

Understand the risk of any change

Home » Blog » Understand the risk of any change
Home » Blog » Understand the risk of any change

Any change, no matter how small – has inherent risk. In the worst case the change breaks the org and business users cannot get their job done which erodes their trust in the Salesforce development team. Or maybe even worse is the change does not break the org, but there wasn’t enough detailed analysis done, so what was built does not meet the business users needs and the new functionality is not used.

We recently sync’d an org that had 256 record types on Opportunity. The object had 130 picklist fields, many of which had 100+ picklist values. Every picklist value needs to be mapped to a record type. There were over 5 million mappings. It was clearly a time consuming development project. But the sad news is that ONLY ONE record type had any data. 

Shift Left

The principle of Shift Left is that the earlier a problem is discovered, the cheaper and faster it is to resolve.

The range of issues that can be – and need to be –  to be uncovered as early as possible in the project are:

  • What are the true business requirements to make sure we are building the right functionality?
  • What is scope of the business change as this determine change management and user training required and any potential regulatory issues?
  • What is scope and the impact of the changes on the org from a technical perspective, and are different teams or different requirements making changes to the same metadata items so there is a conflict?

This last point is becoming a major issue for Salesforce implementations. With the power of the platform  – think how much you can now achieve declaratively with Flow –  the complexity of orgs increasing. Also orgs are becoming strategically important, so any problems or downtime is felt across the whole business. So, it is now impossible to estimate the risk of any change manually, for all but the simplest of changes. There are now too many metadata items with too many dependencies. 

But this analysis is now automated by Change Intelligence platforms.  

Salesforce industry analysts InVisory help companies evaluate and select the best apps in the Salesforce ecosystem. Their recent vendor report rates Elements as the front runner in Change Intelligence Platforms and the most complete Salesforce solution for managing change.

DOWNLOAD the report

FUN FACT: Elements.cloud has analyzed over 15 BILLION metadata items. If it took you 10 seconds to analyze each metadata item, that would take you 23,674 years

Change Intelligence

A Change Intelligence platform can provide the insights that teams now require to be able to manage Salesforce effectively. It provides the documentation to track changes from idea through to implementation, and the insights to understand the risk of changes so that they can be scoped and managed correctly. 

The Change Intelligence platform org analysis fills a clear need. It is more powerful than Salesforce Optimizer which is a great high level view or the org but does not get into enough detail to make decisions. The Where-Used button is only on a limited set of metadata so it is difficult to understand the full picture. The DependencyAPI when it launched in beta 3-4 years ago showed great promise. It has a limited scope and hasn’t been updated to reflect the last 3 years of Salesforce releases. Salesforce recently confirmed that are no plans to update or maintain it. Think how far Flow has come in the last 3 years and the potential dependencies. 

A Change Intelligence platform builds a database (metadata dictionary) of all metadata and then performs the analysis.  

  • WHERE USED – Where is every metadata item used by other metadata items. But then what are the ‘knock-on” dependencies down multiple levels. We call this the dependency tree
  • HOW USED – You need to know more than just that a metadata item is used, but how it is used.  For example; if a field used in a report as a column it is less of an issue, but it is is used in a filter it has a more material impact.  How is a field used in a Flow – in which steps and how many times.
  • WHEN USED – Combining Salesforce event monitoring data and field population data you can get a picture of the usage of metadata. This can be used to determine the risk of making a change, but post-implementation you can see if the functionality is being adopted.

Seeing the full picture

Armed with this information, which is aggregated and presented in an easily understood visual format, you can start to understand the risk and time to make a change. Below is a screenshot of a dependency tree for the field Stage on Opportunity

Helping business users make intelligent decisions

Sometimes “No” is the right answer.

Our team spent time with the business users understanding the real requirement and captured it as a business processes. They looked at the data model to understand any changes that needed to be made. They were then able to scope the technical changes and estimate the effort it was going to take to implement the changes. When this was presented back to the business users, they decided that they didn’t want the team to spend the 6 weeks to make the changes. There were other more impactful requirements they wanted the team to implement. You could consider the time taken on  the business analysis time was wasted because the changes were not delivered. But the change intelligence meant the team were able to provide the business users with the information to prioritize the changes that they wanted so they got the best ROI from the investment in Salesforce.

The final word

Use a Change Intelligence to provide automated org analysis and documentation to increase the speed you can make changes with confidence. Then you can prioritize changes based on the level of risk and the effort to deliver. You can also fast-track low-risk changes and allocate the correct level of development resources to every change.

Photo by Loic Leray on Unsplash

Back to News

Continue reading

Read more news and updates from Elements.