The "Where is this field used?" feature was a Salesforce new winter’20 release. This feature of the Salesforce was certainly a question, numerous Salesforce Executives and developers generally desired to answer. The clear requirement of Where Used was highlighted by those in the Salesforce ecosystem, acquiring a magnificent aggregate of 36,000 points on the Ideas Exchange which is the sharing and balloting platform for the future Salesforce features. In this article, we will discuss the new Where Used button in Salesforce.
As Salesforce is growing more tactical and has an extensive scope across your organization, the risks are more advanced to recover without disturbing business strength. Without a complete guide of Where Used analysis, you are flying blind as you make alterations to your organization.
Overview of the new Where Used button
Salesforce has introduced a new Where Used Button on custom fields in Setup (beta in Sandboxes). On clicking it, a new panel with a record of the center metadata types is opened where a field is used. The previous method of trying to delete a field to uncover its usage is used here as the logic behind this is being disclosed as the Dependency API. Inclusively, they have added reports which were a big question by management.
“Where is this used” Button
The future scope of Where Used and the Dependency API
The new winter’20 release was just beginning but is a vast leap onwards. The Where Used button only deals with the custom fields, it does not look at all metadata items. The Dependency API takes a while to run and it only returns the earliest 1,000 outcomes, and burns through your API limit. This is a serious issue for organizations with 1,000 of apex classes and reports.
Salesforce is evolving an Asynchronous API for the developers looking to experience Where Used in large organizations, but for the best optimization of API calls and results, the developers will need to write some code.
The Dependency API needs to be expanded, as the Salesforce non-platform applications such as Einstein, Pardot, Mulesoft, and Salesforce commerce cloud use platform pitches. The well understanding of the field usage you have, the easier and faster it is to evaluate the risk effect of making modifications to it.
Dependency API: Find all the referenced Metadata
Is this the culmination of some AppExchange Applications?
Not certainly! Any application that offers the “Where Used” type probe might be capable to use the Dependency API to execute some of the heavy lifting.
• Applications are capable to look at a wide variety of metadata types, and so offers a more in-depth examination than the Where Used button.
• Applications might be capable to show or report on the examination in a more suitable format. Managers need to contemplate the budget and benefits of this additional examination. Management with admittance to developer skills might be able to utilize the Dependency API to obtain the examination stated the way they need it.
• There are many applications available that offer more than one Where Used field. They support a more rigorous impact evaluation and the management of organizational changes. For them, “Where Used” is just one of their features and they can utilize the Dependency API to lessen their development pains.
Creating an Impact Evaluation Strategy
“Where Used” field is part of your Impact Evaluation Strategy, which would be a fundamental step in your execution procedure. The Impact analysis should begin with the needs and business change, and then the scope of various metadata products impacted. The primary question is what other business procedures and other parts of the business utilize any of these metadata items, and what effect will the alterations have on them? If the contact termed as a support level that you need to modify is also used in a flow. An ideal method is a Data Dictionary where every metadata has where used examination and also has links to:
• Customer stories.
• Procedure maps.
• Screenshots and so on.
Then it is fast and simple to conduct the impact analysis to a level where alterations can be made with self-reliance.
Designing your Impact Evaluation Strategy
When designing your impact evaluation strategy, you should consider the following facts:
What things in the Delivery Cycle do you do the Calculation?
The prior you do it, the inexpensive it is. Holding it in Business and data design is 100 times cheaper than in build and 1000 times cheaper than in manufacture. Though, you need to implement severe requirements capture and business analysis. It is the most rapid method to drive up user acceptance and implementation.
What Kinds of Risks are you ready to Admit?
You need to implement an irrationally in-depth level of the impact evaluation study. The new “Where Used” button is now accessible which will eradicate a heap of astonishments.
Data Dictionary and Documentation Strategy
The keystone of any impact evaluation policy must be a Data Dictionary and a proper methodology documenting modifications as you make them. This intensely decreases the impact evaluation budgets because it delivers the raw data for any evaluation rather than having to assemble it for every change.
Does Making Particular alterations affect Impact Evaluation?
Inserting a new field requires a different level of evaluation than performing a new managed package; however, you should be assessing the effect of a requirement and the relevant user stories, not metadata variations. You are just inserting that new picklist item because the business methodology has altered.
The new winter release’20 was a vast leap forward when it approaches to Where Used and the Dependency API. The Where Used button is for custom fields and it will open a new panel with a record of the essential metadata types where a field is used. Moreover, they have added reports which were a big question by Managements. This is just the beginning for the Dependency API, and organizations becoming accountable for making their impact Evaluation Approach.