Bulk field impact analysis

[mtywright]

Feature Idea: Bulk field impact analysis
Functionality: Allow the user to input/select multiple fields on an object to be analyzed for dependencies.
Need: When preforming org maintenance or re-architecture often there is a need to better refine object definitions. This includes deleting obsolete fields. In order to scale the effort required to do so, as well as creating a foundation for regression testing, impact analysis for each field is needed.
User Story: User connects to their sandbox with happy soup. User either inputs a list of fields, or is offered a list of fields to select. Happy soup returns a digestible list of each metadata reference for each designated field field.
Current Workaround: Currently, the user must use happy soup (or the 'where is this used?' button on the field detail page) to record the impact analysis for each field one by one, which takes a lot of time especially when analyzing hundreds of fields.
Additional Comments: Although this additional functionality will take substantially more time for happy soup to output a result (proportionate to the amount of fields selected), It would still be a huge time saver over preforming an impact analysis for each field one by one. Also, thank you for developing such a wonderful tool!

[pgonzaleznetwork]

@mtywright this is a great idea! My initial thoughts is that if I enable this, it'd be for a limited amount of fields at the time, say 10. In your experience with this use case, approximately how many fields are you looking at, and would they all belong to the same object?

[mtywright]

I can answer your question in the context of a salesforce partner vendor with Capgemini. When the client asks my team to delete redundant fields, it's usually because the number of fields they currently have on a specific object is causing a problem. Either they are running into timeout errors, SOQL errors, or even the salesforce governor limits. So I would say we are looking at somewhere between 100-500 fields. And yes we would take it one object at a time.

I usually then run data analysis on the specific object to determine what fields are currently being used. Once I have a list of fields with little to no data, I then would need to run an impact analysis in order to determine how much work it would be to delete the fields. For example, if a field with no data is only being referenced in reports/report types, it is a simple matter of just hitting the delete button. However, if the field is on a layout or some other UI, I would then need to take that information to the client to understand why they are not using the field. If the field is referenced by some sort of automation such as an apex class or a flow, I would need to edit the field out of that automation. So for these reasons, even simply knowing where a field is being referenced goes a long way in determining the effort for this type of client requirement.

[pgonzaleznetwork]

Makes sense! I'll definitely work on this in a few months, once I'm done with the UI rearchitecture. Also, it'd be great if you could join our slack channel so you can be notified of updates in real time! https://join.slack.com/t/happysoupio/shared_invite/zt-oo8d5a1t-A04m7wkK16vwdd5oWtpbZg