Knowledge Base

Our Knowledge Base is one of Support’s most powerful tool. Here we store all of the information we need to best help customers as well as content geared towards customers on how to troubleshoot, triage, and fix common issues they may encounter.

Create a Knowledge Base Article

We want our knowldege base to be organized and structured. Below is the outline to follow when creating your knowledge base articles.

Search

  • Article #1 (Structure continues to each article)
    • Scenario
      • This is where we’d describe a use case
    • Problem
      • This is where we’d explain the problem or issue faced
    • Troubleshooting
      • Steps go here
    • Solution/Workaround
      • The good stuff
    • Additional info
      • Known issue link /Bug fix link etc

Code Insights

  • Article #1 (Structure continues to each article)
    • Scenario
      • This is where we’d describe a use case
    • Problem
      • This is where we’d explain the problem or issue faced
    • Troubleshooting
      • Steps go here
    • Solution/Workaround
      • The good stuff
    • Additional info
      • Known issue link /Bug fix link etc

Code Intelligence (SAME AS ABOVE)

Batch Changes (SAME AS ABOVE)

Docs vs KB

We have some documentation and troubleshooting guides in our docs, so it can be confusing what should live in the docs vs in a KB article.

Anything in the docs should be content that is static is not meant to change. This can be things like concrete setup steps for a specific use case or a product overview. A KB can be more dynamic, meant to capture the latest troubleshooting steps for issues customers may encounter.

Additionally, there are two types of KB articles:

  • Internal KB - These are KBs meant for the Support team. These are articles that will make SEs lives easier. Troubleshooting guides, playbooks, gotchas that we may run into that are not applicable to customers.

  • External KB - These are KBs meant for our customers and partners. They outline troubleshooting steps, solutions, workarounds to common issues customers may encounter. They’re about quick FYIs or solutions that may change over time.

An example of an external KB can be a bug that was found on a specific deployment type that has a workaround. We don’t expect this to be needed forever but until a fix is made and most of our customers are out of that particular version, it can serve as a way for customers to resolve the issue they are seeing.

Overall, docs are meant to be more permanent, KBs don’t have to be and can expand in many different directions to avoid a customer asking a question and be able to troubleshoot something themselves.

If you’re ever in doubt about whether something should be a KB or a doc. Ask the team! We’re happy to discuss and point you in the right direction.