“Where is this Field Used?” was clearly a question many Salesforce admins and developers frequently wanted to answer, if not daily. The clear need for WhereUsed was signalled by those in the Salesforce ecosystem, racking up a grand total of 36,000 points on the IdeasExchange, the sharing and voting platform for future Salesforce features.
Without a complete picture of WhereUsed analytics, you are flying blind as you make changes to your Org. As Salesforce becomes a more strategic and has a broader scope across your company, the stakes are higher to innovate without disrupting business continuity.
Overview of the New WhereUsed Button
Winter ’20 delivered a WhereUsed button on custom fields in Setup (beta in Sandboxes). Click it, and it will open a new panel with a list of the core metadata types where a field is used.
Know that old trick of trying to delete a field to reveal its usage? The same is at play here, as the logic behind this is being exposed as the Dependency API. Plus, they have added reports which were a big ask by Admins.
The where used results for a custom field in standard object
The future of WhereUsed and the Dependency API
The Winter ’20 release was just the start but is a huge leap forward.
- WhereUsed does not look at all metadata items (more in the roadmap)
- Is only for custom fields
- The Dependency API only returns the first 1,000 results and takes a while to run, and burns through your API limits (an issue for Orgs with 1,000s of apex classes and reports).
For the developers looking to exploit WhereUsed in large Orgs, Salesforce are developing an async API, but developers will need to write code so that that optimizes API calls.
As Salesforce non-platform apps like Pardot, Einstein, Tableau, Mulesoft and Commerce Cloud use platform fields, then the API needs to be extended. The better the picture you have of field usage, the quicker and easier it is to assess the risk impact of making changes to it.
Is this the end of some AppExchange Apps?
Not necessarily! Any app that provides where used type analysis may be able to use the DependencyAPI to do some of the heavy lifting:
- Apps are able to look at more metadata types, and so offer a more comprehensive analysis than the WhereUsed button.
- Apps may be able to display or report on the analysis in a more useful format. Admins need to consider the costs and benefits of this additional analysis. Admins with access to developer skills may be able to use the DependencyAPI to get the analysis reported the way they want it.
- There are apps that deliver more than just where used. They support a more rigorous impact assessment and the management of org changes. For them, where used is just one of their features and they can use the Dependency API to reduce their development effort.
Creating your Impact Assessment Approach
Where used is part of your impact assessment approach, which should be a key step in your implementation methodology. Impact analysis should start with the requirements and business change, and then the scope of the different metadata items impacted – where a field is used is critical.
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 what about the ‘why’ and the ‘how’?
The best approach is a Data Dictionary where each metadata has where used analysis and also has links to:
- User stories,
- Process maps,
- Screenshots etc.
Then it is quick and easy to conduct the impact analysis to a level where changes can be made with confidence.
The data dictionary in the right panel for the Budget field in the Project object with access to the documentation, usage, access, GDPR and feedback tabs
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 Data Dictionary and Documentation Approach?
The cornerstone of any impact assessment strategy must be a Data 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).
When it comes to WhereUsed and the Dependency API, the Winter’20 release was a huge leap forward. The WhereUsed button on custom fields in Setup will open a new panel with a list of the core metadata types where a field is used – plus, they have added reports which were a big ask by Admins.
This is just the start for the Dependency API, and organisations becoming responsible for creating their Impact Assessment Approach. I hope you found my pointers above helpful as starting points.
About Elements.cloud Catalyst
What Admins and Consultants have been searching for is a simple, easily implemented and repeatable approach for clean up, analysis and documentation. It also needs to work for any size or complexity of Org structure. And it must be broader than Salesforce.
We’ve spent the last 4 years building Elements Catalyst to provide a robust tool that supports the implementation lifecycle which is why we win DemoJam after DemoJam. We are finding that customers are able to build the justification for a more robust impact assessment approach that extends Where Used. The free trial set up takes 4 clicks and 2 mins. The nightly analysis on your Org will be insightful (and potentially scary).