Checkflows are a legacy flow type. If you do not have existing checkflows, we recommend you disregard this document and look into new flows instead.
The nodes in a checkflow are called symptoms. There are a few different types with different properties.
These are the issues that a user can directly observe in a product. If a user is attempting to troubleshoot a product, the actual problem they are having can be phrased as an observable symptom. For example, "the device does not power on when I press the power button" would be an observable symptom.
Observable symptoms are presented to users as yes or no questions asking whether the symptom is present. For example, the user may be asked, "Does the device power on when you press the power button?" In this case, if the user answers "Yes" that would indicate that the symptom is present, and thus in the "faulty" state. A "No" answer would indicate that the symptom is not present and that it is not faulty.
Observable symptoms are shown in the assistant builder as white boxes with solid borders.
These are the underlying causes of observable symptoms. Fixing them is expected to resolve the observable symptom. For example, "the power cord is unplugged" may be the fixable symptom behind the observable symptom of a device that won't power on.
Fixable symptoms are presented to users as instructions that may solve the problem. For example, the user may be told that a potential solution is to confirm that the power cord is securely connected to both the device and the power outlet. The user is then asked whether this solved the problem - if so, the support issue is resolved; otherwise, the assistant will keep going to other symptoms as determined by the flow.
Fixable symptoms are shown in the assistant builder as yellow boxes with dashed borders.
These are issues that a user cannot directly observe but which may cause different observable symptoms and also be caused by different fixable symptoms. For example, a device may have corrupted firmware. This could be a hidden symptom causing an observable symptom that the device does not start up or gets stuck in a boot loop. It could also have different fixable symptoms including the need to flash the firmware or to perform a factory reset.
Hidden symptoms are never presented to users. Instead, they are useful for keeping flows more organized. For example, it would not be useful to ask a user if their device's firmware is corrupted, as this is not something they can confirm directly. However, within the flow it would be useful to connect both the "Does not start up" and "Stuck in boot loop" observable symptoms to a "Corrupt firmware" hidden symptom, which is then connected to "Firmware needs to be flashed" and "Factory reset required" fixable symptoms. This is easier to understand and maintain than connecting both observable symptoms directly to both fixable symptoms - especially if new observable or fixable symptoms later need to be added.
Hidden symptoms are shown in the assistant builder as gray boxes with dashed borders.