When you are stuck at an impasse - or finding that something in Slate is not working as you intended - it is important to follow a process to help you uncover a path forward. The below process is our recommendation for approaching a situation in Slate where you're stuck or unsure. Often, "troubleshooting" implies that there is a problem that you are aiming to solve. While there could be a problem that you run into, it can also be a behavior that you are unfamiliar with. The goal of following this process is to help you get to an answer by unearthing more details about the situation you are experiencing, better understanding Slate, and testing potential solutions. You may find a solution as you navigate this process, or you can use the details you uncover to provide better intel to others who are helping you troubleshoot.

Step 1: Describe the Behavior

• Where does this occur in Slate? - Typically, this is where you first notice the behavior. 
• External Integrations - Are there any external integrations that need to be considered?
• What are the symptoms? - Investigate both the user experience and the administrative setup. Determine symptoms from both angles. What do you expect to happen that is not happening Are there any error messages or logs displayed?
  • Who is experiencing the behavior? Use the Query tool to see patterns among particular records by reviewing exported data. You can even create queries from forms or events. If the behavior is user-based, impersonate other users. Is this affecting users of Slate or objects (ex., forms, fields, etc.) in Slate?
  • Does this affect one user/record or many? What patterns do you notice based on who is affected?
• When does it occur? Review a record's Timeline (especially the Audit Log), the Job Activity Monitor, Error Log, and Access Log to see timestamps. Provision a Timewarp to determine if the behavior existed at or before a particular time.

• • When did the behavior start?

  • Is it only at specific times?

  • How frequently does it occur? Is there a notable pattern?

  • Develop a timeline of events leading up to this. Does a sequence of events need to happen for the problem to occur?

  • Under which conditions does the problem occur?

  • Do any other objects fail at the same time? Are there successive failures?

• Can the behavior be reproduced? Create test objects (records, events, etc.) to replicate this problem. If you cannot replicate the issue and it only happens to one person or object, consider manually correcting the problem until a pattern is discovered.

Step 2: Experiment

Using the deductions you've made from the questions above, try to remove as many elements as possible to identify the potential problem and what may be causing it. To help you eliminate non-issues, review configurations of objects to ensure they are configured according to best practices in the Knowledge Base.  

Even if you don't know why, do your best to develop a hypothesis as to what is creating this behavior. A good place to start is with the most obvious cause, such as objects needing to be configured according to best practices in the Knowledge Base.

Step 3: Create a Plan of Action

Determine an initial testing approach using a potential solution

• Consider testing in the Test environment vs. testing in Production

• Consider the repercussions of where you're testing (could testing impact live records)?

• Is this able to be tested in a controlled environment in Production

• Does the Test environment enable you to perform all necessary functions to test this solution?

Step 4: Test the Solution

Consider: Check the Knowledge Base in the area you are testing (ex., Troubleshooting Rules or Troubleshooting the Person Record) to see if there is documentation with testing suggestions.

• Did that resolve the behavior? If not, did it provide any additional insight to help your next attempt at finding a solution?

Step 5: Document and Adjust

Ensure you document the results to help you improve future troubleshooting.