In my career, I have transitioned from a Salesforce.com Developer to a Salesforce.com Consultant. In this article, I portray how I have tried to change the way I work by starting at the 'Why', instead of jumping into the 'How'.

I started my Salesforce.com career as a developer. I learned Apex and Visualforce and immediately got hooked on to these relatively easy-to-learn programming languages that gave me the power to build (almost) anything. The following picture aptly portrays how I felt:

I would be asked to build a functionality - a 'What?' - and my job would be to figure out the 'How?':

However, this train of thought completely overlooks the 'Why'? It is very crucial to understand that behind every functionality request lies an intrinsic motivation. So, a revised train of thought would look like:

Let us illustrate the difference with an example.

A Use Case

Let us describe a simplistic client request below:

The standard Salesforce Account object houses B2B Customers. There is a bi-directional flow of information between the Salesforce Account object and certain external systems. Each of these transactions is logged in a separate custom object called 'Interface Transactions'.

It is required that the LATEST Interface Transaction is captured on the Account (specifically the transaction code).

The 'How' mindset:

My solution would involve creating a custom field on the Account called 'Latest Transaction Code'. I have 2 options to populate this field:

Technical Note: Account to Interface Transaction is a lookup-relationship so a Rollup summary is not a viable option.

Result: I am able to take the Process Builder approach and meet the requirement without using code! Yay!

The 'Why' mindset:

It turns out that this functionality request came up since the IT manager observed that the Account interfaces were acting up and it was needed to facilitate random checks on the Account - specifically checking if the latest transaction code is correct.

As we read this again, the phrase that pops out is 'facilitate random checks'. Hold on! This means that we can also meet this requirement if we are simply able to display the latest Interface Transaction on the Account Lightning Page. Hence, my solution approach changes to look something like:

Technical Note: There is an AppExchange package that allows you to create filtered related lists.

Result: I am able to deliver a clean, simple solution that avoids creation of a custom field on the Account and a process builder on the Interface Transaction

Hence, by starting the train of thought at the 'Why', one can embrace empathy in order to arrive at cleaner, simpler solutions.

Thanks for taking out time to read through. I am keen to hear your views and look forward to some engaging comments. I blog at Techfinery, so do check that out for some Salesforce.com goodness.