Category: Support

Salesforce, Support

Yes the Community is THAT Important!

| sudovi

Since I started back with my old company as the Salesforce Practice lead, several firms have contacted me trying to place resources, or I’ve been asked to help “tech” someone applying for jobs at various clients around town.

I recently got passed a resume of someone claiming they’ve had 5 years of experience and carry 5 separate certifications. This person is apparently somewhat local to the area and yet I find no record of this person in any — zero in fact — of the various Salesforce related communities online. Not success, not the stack exchange, not even on twitter or even a blog. In addition, if they’re as local as I’m led to believe, I’ve not seen them at a single user group and not at my dev group either.

While I have no doubt that the person is probably quite capable, I find this extremely alarming. To me it shows zero passion for the platform, zero advocacy. Maybe I’m not being fair, maybe there are extenuating circumstances that I don’t know about, maybe they don’t know these things exist (after five years experience, I find that really hard to swallow).

If I’m given the choice between this person with 5 years experience, and 5 certs but completely unplugged from the community, or someone who maybe has only some of the experience and certs but is regularly attending User Groups, has a success community profile, or stack exchange, and is engaged at all with the community — I’m going to pick the latter.

To me, yes the community is THAT important! Its where the support is at, it’s where you learn the new tidbits and connect with others like yourself and more advanced than yourself, its how you grow. Surrounding yourself with the members of the community I feel is one of the most important things you can do in your Salesforce career and activity within the community is NOT to be overlooked.

If you’re reading this, and wanting to build a career on the platform but you haven’t participated in these channels, it would behoove you to start right away:

Login to the Trailblazer community and create a profile
Visit/browse the Salesforce Stack Exchange Community
Attend a local user (or dev) group, and if you don’t have one, start one! (You can find them listed in the Trailblazer community I linked to above).
Do this, do this now — don’t even finish reading this rant of sorts…

Yes, its THAT important!

:wq!

General, Support

Anyone Can Code

| sudovi

Last week I had the opportunity to help someone who was learning to code through one of the many different programs available to us, the Salesforce community. Whether you’re learning from the RAD Women program, Trailhead, one of the Salesforce provided classes, or simply teaching yourself, you will find at times that you hit a wall where things start to not make sense. Or maybe you start to fall a bit behind when the concepts start getting heavier.

One of the resounding things I hear from people that I’ve helped in this situation is actually rather alarming. What I’m hearing are people saying they feel dumb, or slow, or feeling like an idiot. Please, for the love of all that is good STOP thinking this way. What you are doing is hard, and its new and likely something you’ve never done before. Think of it like learning a new language or learning to play the piano. You wouldn’t sit down after a few short weeks and expect to crank out the Bach, Mozart, Beethoven symphonies would you? It’s all very much the same idea: practice, practice, practice.

I posted a quick Periscope about this over the weekend but seeing as how those things disappear after 24 hours, I thought perhaps instead of posting about my usual stuff, (don’t worry more lightning coming soon), that I’d just post these words of encouragement for those that may need it.

Just keep doing what you’re doing and remember: I’m always here to help.

:wq!

Support

How To Report Problems to Your Support Circle

| sudovi

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!