A related to B with properties is A with B’s properties

This article is more of a rant than anything else. I’ve worked with inherited, undocumented, cluttered, and messy Salesforce orgs in the past. If you have too, then you will know how painful it can be to work and make progress in such scenario as you will have to question every single undocumented field, automation, asset, object as you work your way through. Sometimes it’s much better to start from ground up and build anew but in many cases that’s not an option for businesses due to the years of accumulation of data, automations, institutional knowledge, and simply due to the fear of change in organizations.

It’s common that with every new staff change comes new ideas, initiatives, and efforts to make things better than before. When it comes to Salesforce it’s no different in terms of changes with staff turnover. There are several things a successful Salesforce team can do to ensure proper change management. First and foremost documenting every change in its entirety with as much detail as possible. This will ensure the organization will not suffer from staff changes and also help increase their efficiency with future changes and implementations.

As I said in the beginning that this post is to rant on how I’ve seen some orgs handle their data and less about change management. Sorry for the digression and please let me get back to the ranting part.

In certain Salesforce orgs I am seeing admins create new fields with minimal questioning. In one example, where the opportunity object is directly related with payment object, the sales department wanted to have a “Payment Type” field added to the object. Also worth keeping in mind that the opportunity object acts like a central location where many other objects connect to and run numerous business automations from. You could almost think of it as a “connector-object”.

Now, with the above in mind, the sales team also requested a field on the opportunity object that would identify the type of the opportunity. So now the org has the same data in two different objects, and they are not related or connected to each other in any meaningful way. In other words, the Opportunity of type A doesn’t know if its payment record is of type A or not.

Now comes the part I like the most. The light at the end of the tunnel, the solution. I said this earlier, a well structured and documented change management is crucial for organizations, but so is the understanding of basic data principles by not only the Salesforce admins but the whole staff. I’ve seen in many instances that the word “data” scares people. They know what it is, but they are not comfortable working with it. Salesforce, being a relational database in its core, inherits the basic principles of databases, one of them being, if Object1 and Object2 are related to each other, and if Object1 record is of typeA, then the Object2 record associated with Object1 record inherits this type. In other words, it’s redundant to add the same field to both Object1 and Object2.

For this reason, the fields added with little or no insight, or disconnected fields, usually result in a graveyard of unused fields in Salesforce. As I said in the beginning, with every new staff comes new ideas and requests, and at the end of these requests, if there is no coherent implementation/change management in place and without basic data training, the organizations may suffer from mismanaged platforms.

Thank you for reading through my rant and if you have any questions about this post or have ideas to share please do reach out using the form below.