How I approach troubleshooting any Salesforce issue – A Framework

This is my first post. I’ve mostly been against blogging in the past for one reason or another. I’m like Han and his trusty blaster… Who needs those new fancy lightsabers? However, I’ve come to see that they can be a good outlet that forces me to get some of my thoughts/experiences out there and to keep me accountable for making sure I completely develop those thoughts. Without further ado…

 

I wanted to approach this blog as more of a framework approach to Salesforce. I imagine I will certainly post about specific issues, situations, best practices, etc. but proving frameworks helps everyone be more efficient. As my first post, I wanted to provide a framework on how I troubleshoot any issue within Salesforce. This helps me to collect my thoughts and be efficient with the time I have to troubleshoot the issue.

Here’s a fancy Graph:
How_to_Troubleshoot_an_issue_in_Salesforce_Framework

Tell Me/Show Me

We all have customers. Customers can be internal customers or they can be external customers but in the end we are all customers of one sort or another. The framework I use to troubleshoot any issue is to have the customers Tell Me or better yet, Show me the issue. There is really no replacement for getting eyes-on an issue and having the customer share with you the specific issue, how they are getting to it (i.e. steps to reproduce), and why they are frustrated. This helps you identify the issue but also gives the customer a sense that they are being taken care of. This initial step in the framework could be considered information gathering but it provides much more to than just details. This step gives the customer confidence in you directly. You now know what the customer knows.

If your organizations support process does not include this step you should consider adding it. You will see support metrics improve. Issues that go into a generic “box” that has no face to it doesn’t inspire confidence on the customer side.

What Changed

The vast majority of issues fall into a few buckets. The last bucket in this list is self explanatory and I won’t spend much time on it.

Something Changed – Change it back
Something Needs to Change – Change It
Nothing is Actually Wrong – Do Nothing

In this step we determine which bucket our issue falls into. Based on the information gathering that you did in the previous step you identify what may have changed to cause the error/issue. A simple example provides a good basis for what this step might look like:

Customer Issue: I can’t see field XXX

What Potentially Changed:

  • Field Level Security
  • Page Layouts
  • Field

Now that you identified what potentially has changed you further identify what might need to potentially change to resolve the issue. For our example, they are the same thing:

What Potentially might need to be changed:

  • Field Level Security
  • Page Layouts
  • Field

 

What’s Related

Salesforce is full of relationships and that’s a good thing. Relational databases are useful as are relational features. Knowing and identifying the relationships that are associated to the features that you identified in the previous step will help you to formulate the resolution… which is coming… I promise… In the next step.

In our example:

  • Field Level Security – Related to the Field
  • Page Layouts – Relate to the Object and the Field
  • Field – Relate to the Object, Field, and Page Layout

Mapping out the relationships helps to identify where we look first. The more related the feature is the more value you place on it and therefore look there first for a potential issue. In our example, we would look on the object record for the field that the customer can’t see to ensure that its still there. We would then work our way down the list of related features that we identified.

What’s Missing

If something isn’t working as intended then something is missing; either its missing because something changed or something needs to change. Notice that I didn’t mention that a configuration change is always needed here. A process change might be necessary as well. The previous step helps you to systematically identify what is missing in a setup configuration. In my experience, most issues within Salesforce are resolved by a configuration change of some sort. Knowing systematically what to look at first and what to change helps to efficiently resolve the issue. Once you do find what’s missing, make a change and verify the issue is resolved with the customer.

But what if you don’t find anything in the configuration that needs to be changed? Answer – Something is wrong with your Process! More detail on this in a later post but suffice to say, establishing process is key to avoiding errors and ensuring a happy, efficient workforce.