As a consultant, I see many orgs, have written many many lines of code, and work on numerous projects simultaneously. This is always the case and if you are working with a consultant, they’re likely juggling many projects as well and have also written so many lines of code that one project tends to bleed into another, or perhaps has been forgotten entirely. Many of us don’t have unlimited storage in our brains and usually will need some refresher time when addressing issues.

Many times, when receiving requests for support on a given project, I find myself having to go back to the client to ask for links, background information, text from error messages, etc. So here are my top five things to include in a request for support to your admin, your dev, or quite honestly *any* request to a support team (not in any order):

1. Detailed Description of the problem: Don’t simply say “User A tried to enter an Opportunity but it didn’t work.” There could be a myriad of reasons why this would fail: validation rules, required fields, security, etc. Instead perhaps you could also include the user’s profile, the type of opportunity they were entering if it used a different record type etc. Perhaps the entering of the opportunity worked but something else failed along the way, so maybe even describe how far you got in the process before it didn’t work.
2. Error Message Text: If you are getting an error, it always helps to include the text of that error. Even if it seems cryptic to you, to a developer, some of that “nonsense” talk speaks volumes. Good devs create specific error messages for a good reason. So that when a given situation arises, that information is meant to be shared with the support team. Many times these message would be enough information in and of themselves to help someone address the issue.
3. A link to the problematic record/page: It always helps to provide a link to the specified record or page that is giving you trouble. This way the support personnel can attempt to see the issue exactly how you see are seeing it. Many times, half the battle is simply trying to recreate the issue. By supplying a link to the problematic record, much of that time spent trying to reproduce the issue could be mitigated.
4. Screenshots: Sometimes a picture really is worth 1000 words. In talking with support, you could be using the same terms, and talking about the same thing, but the context is COMPLETELY different. I’m reminded of a story from my helpdesk days where a remote user called in because the key fob he was using wasn’t providing him a code that was working while attempting to login. To make a long story short, our support person found out (after two hours on the phone) that the end user never received a key fob and instead was reading the numbers directly off the documentation that was sent to him…the actual piece of paper. Its all about providing context.
5. A summary: If you ever find yourself acting as the intermediary between support and your user base, you find yourself under a swarm of emails. Whenever providing feedback, it helps to give a summary of anything that occurred between yourself and your user base in between communications. If you simply just forward an email without any commentary, the support engineer needs to hunt through what could be numerous threads to figure out where action needs to be taken. By all means, include the entire thread as it may in fact be necessary for context, but highlighting the areas of that thread that need attention will allow the support personnel to put the focus exactly where it needs to be thereby improving the efficiency of the entire process.

In closing, share as much as possible and provide a summary of that information so that support personnel can put the focus where it needs to be rather than starting from ground zero but is still able to sift back through for an audit trail, etc. Keeping these things in mind when working with support situations should provide you with a smoother, more efficient path to a solution.

:wq!