Getting Help from the ServiceNow Community

As I mention in my recent interview with Robert ‘The Duke’ Fedoruk (9:46), I truly believe that the highest calling of mankind is to learn, and then to teach.
I’m far from the only person in the ServiceNow developer community who feels this way! This fact is obviated by the incredible community of new and seasoned administrators, developers, and architects who are constantly trawling the community and just looking for ways that they can contribute.

That said, if you’ve spent much time in the community, you may have noticed that some questions go completely un-answered, while some elicit dozens of responses within the first hour; and some that receive dozens of responses, are mostly comprised of questions with no real answers.

This article aims to help explain why that is, and to help you ask better questions, more clearly, and get accurate help effectively. If you read this article carefully, you should come away with an understanding of:

  • What leg-work you’re expected to do, before asking a question

  • What information you need to provide in your question, in order for us to help

  • How to format your question so that it’s easy to read and understand

  • Some tips for phrasing your question in a way that makes it clear what you’re trying to do

If you see someone posting a question which doesn’t follow the guidelines mentioned in the Guide to Getting Help section of this article, link them to this article (gettinghelp.snc.guru) and tell them which rule they’ve violated!

When I use the word “rules” in this article, I mean that in a lighthearted kind of way. “Violations” of these rules are not cardinal sins, and aren’t even always wrong. These “rules” are really just guidelines

Pro-tip: To link directly to the “Rules” section of this article, use rules.snc.guru.

Communities

There are loads of great resources for learning about the ServiceNow API, getting basic ServiceNow training, and learning about the platform in general; but when you get stuck, where can you ask questions?
Well, if you’re willing to follow the guidelines below, there are several great resources for getting help. Here are a few of them:

  • The official SN Community forums

    • Pros: Permanent (or semi-permanent). Large community. Decent text formatting options.

    • Cons: Responses can be slow, and much of the community is disillusioned by the Community forums due to the slowness of responses from question askers, and the tendency of askers to “abandon” threads and not mark answers as correct. Posters often fail to mark answers as correct, which negates some of the “gamification” that might otherwise make you want to participate and help out on the forums despite its issues.

  • The unofficial SN Dev community Slack

    • Pros: Fast responses. Large community. Better thread support

    • Cons: Lack of history (messages disappear after a short while). Large community also means the channels can “flow” very fast, and some things are missed.

  • The unofficial SN Dev community Discord

    • Pros: Relatively fast responses. Permanent history (easily searchable). Breakout voice/text/screen-share ‘rooms’ that can act like super-threads and/or group voice/screen-share channels for live help when necessary.

    • Cons: Smaller subset of the community, fewer eyes may be on your question (depending on the time of day).

Other Resources

This article will cover some specific points that are unique or perhaps more specific to the ServiceNow developer communities, and ServiceNow in particular. That said, we’ll also cover some pointers for “asking good questions” as a developer in general. We’ll probably repeat a lot of the sage advice mentioned in some of the existing articles on the topic of asking good questions as a developer; so, to give credit to those that came before, here are some other articles and resources which have also aimed to help developers ask better questions, and get help more effectively:

  1. Bianca Vaccarini’s Community blog post: How to Write Questions that will get Good Quality Answers

  2. Jace Benson’s article: How to get help faster on Community

  3. freeCodeCamp’s article: Read, Search, (Don’t Be Afraid to) Ask

  4. StackOverflow’s help articles: How to ask a good question, and How to create a Minimal, Reproducible Example

Please do feel free to read some of those articles too, as some will cover things that this article doesn’t, and others may have far more detail.

Guide to Getting Help

Below, you’ll find some basic “rules” for getting help and asking effective, clear questions that make it easier for others to help you. When a rule applies mainly to a specific platform, that will be noted at the beginning of the rule.

While you peruse the guidelines below, also consider reading this excellent episode of the ServiceNow Podcast CJ & The Duke. In this episode, they discuss and share some sage advice about how to get help from the community, what steps you need to take before reaching out, and how to interact with those you’re trying to get help from, in a way that’s most likely to get you the help you’re looking for.

 
 

  1. First and foremost: Try to solve your own problem first! This is probably the most critical step.
    This not only might save yourself and others a lot of time, but will show people that you’ve done your due diligence, and are therefore someone who’s going to be much easier to help.

    1. The bare minimum version of this, is searching Google for your problem. Try a few variations on your query.

      1. Imagine you were going to post your question to the community. What would you title your post? Try entering something similar to that into Google, and see if anyone’s asked a similar question!

    2. This is most effective when combined with rule #2.

    3. If people can see that you're not trying to help yourself, they'll stop trying to help you!
      Demonstrate that you've at least tried to solve the problem on your own, by telling us what you've done and linking any articles you tried to use for help, including how you adapted them for your specific use-case and any specific code you used (see rule #2)

  2. Always include any steps you've already taken and any articles you've tried to use to solve the problem, including all of the exact code that you've used.

    1. When mentioning steps you’ve already tried, don’t just say “it didn’t work”; tell us exactly how it didn’t work. Mention what you expected to happen, and exactly what actually happened. Include screenshots if possible. The more we know, the more easily we can help!

    2. Include any specific errors, messages, or other behavior you noticed when trying your solution(s).

    3. If you didn’t find anything useful for your problem when searching Google, consider mentioning the exact search terms you used.

  3. Always post your code when asking a question about code.
    Don’t say “hey, I’m trying to hide a field using .setDisplay(‘field’, false) but it’s not working”
    Instead, I mean, do say that, but then also include the entirety of the code so we can see that you’re using g_user.setDisplay() instead of g_form.setDisplay(); or that you’re using .setDisplay() on a line that will never actually run because it follows some code that has both an if and an else block, both of which have return statements in them.
    Point is - post your code, and post your complete code. It really helps us, help you!

    1. No, I said post your code; don’t post a screenshot of your code - or, god forbid, please don’t post a cellphone photograph of your screen with your code on it… ever. Please.

  4. When posting your code (which you should always do, if the solutions you’ve tried involved code), always be sure to format your code properly on the platform you’re posting it on. Never just hit CTRL+V and post - always use the formatting tools at your disposal.
    If you’re not sure how to format code on a given platform, here’s a quick primer:

    1. Discord & Slack: If your code is a single line, wrap it in backticks `like.so()`. For muti-line code blocks, use three backticks before and after your code block ```like so```.

      1. Backtick is the same key as tilde on your keyboard (but without holding Shift); probably right above Tab, and below Escape.

      2. On Slack, you can also select/highlight your code, and press CTRL+SHIFT+C to format a single line of code, or CTRL+ALT+SHIFT+C to format a multi-line code block.

    2. Community forums: When posting a question or reply on the SN Community forums, in the rich-text formatting bar at the top of the editor, you’ll see an “Insert/Edit code sample” button that looks like a semicolon wrapped in curly braces ({;}). Click this button to open a dialog in which you can select a language, and paste a multi-line code snippet.
      For single-line code, click on the drop-down at the top-left of the editor that says “Paragraph”, and select “Preformatted” with your single-line code selected.

  5. When you post a question, respond to clarifying questions in a timely manner.

    1. Don’t ask the question if you don’t have time to be responsive to people trying to help answer it. Instead, wait until you can have a back-and-forth with anyone who replies, in a timely manner.
      There’s little that’s more frustrating than trying to help someone who has apparently abandoned their own question only minutes after posting it.

    2. This is especially important on Slack and Discord, where real-time communication is expected.

  6. Ask specific questions; not generic ones.
    Sure, some level of generality is fine, but posting a question like “I’ve never set up Discovery before. How do I do it?” is asinine.

    1. Before posting a question, think about how it could possibly be answered.
      If someone asked you “I’ve never cooked food before; how do I do it?” - you might rightly be annoyed. In addition to making it clear that the person hasn’t even bothered to do the bare-minimum by googling their question and learning a little bit about some of the basic techniques of cooking, they’ve also asked an essentially unanswerable question. There is no way to answer such a vague and unhelpful question without writing nearly an entire book on the topic, or asking dozens of follow-up questions to get at some of the specifics of what they’re actually trying to do, and providing information and resources on those specific things one-by-one. (See rule #6)

    2. Remember: the community is not paid. We’re all just fellow nerds who learned the same way you are, and who are grateful to the community that existed back in those days, so we’re trying to give back by helping the next generation of developers just like we were helped.
      So please, don’t make it so we have to pull your teeth out, as it were, just to get a hint of what you’re actually asking, so we can help you.
      The harder you make it to help you, the less likely you are to get quality help, or any help at all.

  7. Don’t ask questions that require clarification.
    (Note: Do ask them; just include enough information that it hopefully shouldn’t require any further clarification of what you’re asking. Just do your best. ♥)

    1. This is similar to rule #5, in that you should carefully consider how the question could be answered, given the information you’ve provided.

    2. Nobody expects you to already know the answers to your own questions, but think carefully about whether you’ve provided enough information for someone to be able to answer your question, or if they would have to ask you a bunch of follow-up questions.

      1. If I ask “How do I compare the values in two fields in a script?” - you can’t really answer that question without knowing more.
        Is it a client-side, or server-side script? - Are they the same type of field? - What have you already tried?
        Any obvious questions that someone is likely to ask, should be answered by you, preferably in the same post as the question, or at least in an immediate reply on the thread.

  8. Slack & Discord: When posting a question, write out the entire question - carefully and thoughtfully - and then press Enter.
    This applies to responses within threads as well as to your initial question. Try to respond adequately and thoroughly within one message at a time, even if you respond to multiple people and questions in a single reply message.

    1. Do not post your question in 5 separate messages, like “Hey guys” [enter] “I have a question” [enter] “I’m trying to get this script working…” [enter] (and so on…).
      This is really annoying for several reasons; one of which is that this can spam people with notifications. It also makes it unclear which of the multitude of messages should be the base for the thread about your question. Finally, it also clutters the channel and makes it much harder to follow and parse, especially if someone asks another question in between two messages you posted about your question.

    2. A single question should have a single base message and a single thread. There are very few exceptions to this.

  9. If responding to a specific person, tag them.
    If responding to a specific question or comment that isn’t the one immediately preceding your reply, quote it.

    1. This makes the thread of conversation and your responses much easier to follow, for anyone who doesn’t see your question immediately, but comes in looking to help a bit after it was initially asked.

    2. This also makes sure that the person who said the thing you’re responding to, knows you’ve responded to them.

  10. Don’t abuse tags or DMs. Tag people who are part of the conversation, but do not just automatically tag anyone who you think might be able to help. We all have day-jobs, and volunteer our time for helping the community when we can. Tagging specific people just because you’re not getting an immediate response is extremely rude and presumptuous. Those people are busy, too.
    This applies equally to tagging someone within a channel, and DMing someone who hasn’t asked you to (especially since moving your question to DMs means nobody else can see the answer and troubleshooting process, so nobody else can learn!)
    There are two primary exceptions to this rule:

    1. If someone’s given specific permission to tag them in this way.

      1. But, don’t ask someone if you can tag them on all of your questions just because they’ve been helpful.

    2. If you happen to know that someone is an expert on the specific topic you’re asking about, and your question has gone un-answered for long enough that it’s scrolled at least two “pages” so it’s no longer visible in the main channel without scrolling by a good margin.

  11. If you find a solution elsewhere, post the answer to your own question.
    Never, ever just say “nvm figured it out lol”. Tell us how you figured it out.

    1. This is one of the ways that you can give back to the community even before you can tackle other peoples’ questions on your own.

  12. Give credit to those that help you.

    1. Community forums: If someone posts an answer that’s correct, mark it as correct. Failing to do this is a massive breach of community etiquette.

    2. Slack/Discord: If someone helps you, tag them and add “++” after their name.
      For example, my username on Slack is @Professor, so if I help you out, you might post a reply on your question’s thread, that says @Professor ++.

      1. The points are meaningless, but they are tracked, and are just a nice way to say “thank you” to someone who’s helped you.

      2. Unlike on the community forums, using “++” on Slack or Discord doesn’t mean that an answer was “the singular correct answer”. It simply means that a response was helpful. You can give away “++” points like candy to everyone who was helpful within a thread, even if they didn’t end up answering your specific question.

  13. Do not try to get the community to do your job for you.
    Nobody should be expected to know everything, but if you’ve never written a single line of JavaScript before, you should be taking a JS course; not asking questions that can be easily answered by Google.
    If you’ve never done ServiceNow development before, you should be taking some SN Dev training or reading a book on the topic, not copy-pasting from your requirements doc into the community and expecting someone to literally do your job for you for no pay.

    1. If you’re being paid to do something, you should have some idea of what you’re doing; but that doesn’t mean it’s your fault if you don’t know something yet! Just don’t expect the community to do it 100% for you, start-to-finish.
      Instead, ask your manager to provide some budget or resources for training! As I mention in my article on ServiceNow as a career-path, this is a perfectly reasonable request!

    2. Not knowing how to do something specific is not the same as trying to get the SN dev community to do your job for you. If you have a specific question, please don’t let this point scare you off from asking it!
      Remember that impostor syndrome is real, and if you ever feel like “I’ll never be a real developer!” - realize that most of us (myself included) felt the same way at some point.
      All that rule #12 is asking, is that you try to use the resources at your disposal to try to learn the basics and solve your own problems before you come to the community asking for us to help you, and try to avoid asking questions that are tantamount to “do it for me”.

  14. Tell us not just what you’re trying to do, but why you’re trying to do it.

    1. Maybe we know a better way. Maybe it’ll help us understand your situation better. Maybe we’re just curious. In any case, this is crucial information to include in most questions, especially ones of a complex nature.

    2. For a more detailed explanation as to why this rule is so important, check out http://xyproblem.info/!

  15. Don’t just say “Hello”. Instead, get to the point. I realize that when people send a separate message (and notification) with just “hi”, they think that they’re being polite… but they are not. It notifies everyone in the channel/message multiple times, and after the first one is a pointless “howdy”, the rest will often just be ignored.

    1. As annoying as a message that just says “what up” followed by a minute or two of silence while you write your actual question is, it is ten times more annoying to get a “bonjour”, and then have your conversational partner just wait for you to respond.

    2. Read https://nohello.net - this hilarious and extremely apt site will guide you! I wanted to copy/paste a lot of their points here, but I’d rather direct the traffic to their site - so please do check it out!

  16. Post screenshots, but don’t crop your screenshots! — Or at least, don’t crop them more than is absolutely necessary.

    1. When asking for help, it’s very, very often a good idea to include a screenshot of what you’re seeing; whether it’s an error message or a field misbehaving on a form, or whatever - your words may paint a picture, but a screenshot leaves nothing up for interpretation; and while I believe that writing code and troubleshooting can surely be an art, it’s not an artful idea that will help us help you. It’s facts.

    2. By the way: Do not post screenshots of your code. This goes doubly for cellphone pictures of your code. (Seriously, why do people do that?) Just post the code! Copy and paste it. That’s all there is to it.

  17. That which is bestowed to you, in the fullness of time, return to that from whence it came.
    Er, uh, that is… if the community helps you learn and grow as a developer, try to return the favor whenever you can.
    As a new developer, nobody expects you to answer a question for every one you ask; but over the course of your career, try to return and help out anyone you can now and then.