First, a fact: Software is logical.
One thing that I love about my job is that people come to me with interesting problems. Plying my trade and understanding the situation regarding the issue, finding a resolution, and communicating this with my customers is a real blast. I’d even go so far as to say it’s an adrenaline rush. Yes, I admit it–I’m a hapless nerd who still loves the thrill of a good hunt. So let’s get to it: Here are a few of the Salesforce troubleshooting tips that I follow to solve problems fast and keep business flowing.
Salesforce Troubleshooting Tips, Phase I: Research
Before I even think about touching a thing, I stop to think. I need a game plan to understand the nature of the issue before rolling up my sleeves. Generally, there are two types of issues:
- A bug–an undiscovered issue that’s been there all along.
- A problem with something that worked before, but now it doesn’t. I’ll call these “lizards.”
Either way, researching the issue requires similar diligence. Here’s a list of questions and things that I check prior to even logging into the org to have a look:
- New Salesforce release?
- New application installed in the org?
- If part of an app, did anything change with the application version, support, or something with an endpoint outside of Salesforce?
- Check trust.salesforce.com–anything going on?
- Ask the user to give all possible details on the issue:
- What time of day?
- What happened (or didn’t)?
- Specifically, what should have happened?
- Error messages
- Links to the records that are causing the error
- Click paths, to replicate the error
- Any changes in the company or policy, or did the administrator do anything?
- Any password changes that could have impacted an integration?
Next, I will log into the org (production instance) and look at a few more things:
- Check the setup/audit trail and see if any changes were made in the org that could cause an issue
- Review the record for signs of any obvious errors (An example: I recently resolved an Echosign issue which ended up being due to a malformed email address on a record)
- Look at the user’s security settings to gain an understanding of what their general permissions are
Salesforce Troubleshooting Tips, Phase II: Replicate
After I’ve completed this assessment, I’ll attempt to replicate the issue. First, I do this as an administrator, to see if it’s a systemwide issue. Next, I’ll log in as the user (assuming it did not occur when I was an administrator), following the user’s instructions on how the issue occurred. If I can’t replicate it, I’ll get on the phone with the user and have them replicate it for me via a screenshare. If the user can’t replicate it, and neither can I, I’ll request that the user monitor and report if it occurs again so we can try to better nail down the conditions that caused the issue.
Salesforce Troubleshooting Tips, Phase III: Resolve
Assuming we’ve replicated the issue, now we need to proceed toward resolution. There’s no surefire formula to this, but here are some tips given the two types of issues mentioned above:
Bugs – Bugs are tough to resolve because they’re usually the result of an inherent flaw in the design. If the bug is related to a 3rd party application, resolution often requires replicating the issue with their support team and then getting their recommendation for the best workaround. If it’s something built in-house, it’s time to do some root cause analysis on how the use case that’s causing the error condition was overlooked. Sometimes bugs can be avoided by making minor tweaks to the UI to block error conditions. An example would be adding a validation rule that does not allow a negative number which breaks the operation to be input in the first place. Often harder to fix, sometimes a plan B or workaround is needed to hold the users over until an official fix can be architected and deployed.
Lizards – Generally, lizards are the result of a change to the environment, user error, or bad configuration, so tracking these down is your job. Going through all of the items on the pre-flight list, it’s possible something came out of it. If a change was identified, it’s probably your smoking gun, and you’ll need to start either rolling back or modifying other configurations to make things work correctly. As a last resort, I often will turn on debug logs to read the detailed system log that’s produced to try to trace down the details of the error so that a resolution can be designed.
Finally, properly rolling out your fixes is paramount. We’ve blogged a few times here and here about some best practices when it comes to promoting changes to production. Assuming you’re following those steps, the one other thing to consider is REGRESSIONS. Regression testing is a snazzy technical term that essentially means looking for situations where fixing something broke something else. Your mission, should you choose to accept it, is to fix things without breaking anything else. Remember the validation rule I mentioned above? Well, it just broke your test classes because the test code inserts negative numbers. See how tricky it can be? Even the smallest change should always have a data backup, metadata backup, and proper rollout strategy before changing production further.
Finally, always remember what I said at the beginning of this post: Software problems are logical. There IS a cause for that issue you’re facing. It might be mysterious, but by continuing to look at the issue from different angles, you’ll uncover the root cause. Don’t let them frustrate you! If you’re stumped, check out the Salesforce Answers community or the Stack Exchange.
I’ll climb off of my soapbox now. 🙂 Hopefully this write-up on Salesforce troubleshooting tips gives you a few ideas on how to better serve your users in resolving Salesforce issues. If you have any other great Salesforce troubleshooting tips of your own, drop a comment! Finally, we do this day in and day out for our customers. If you’re looking for a 2nd line of defense in your company, our On-Demand Administration may be a great fit for you.
