Troubleshooting in product language

Investigate common problems using the symptoms visible in the Console, and route each case to the right action.

When to use this

• Use it when users report problems without knowing the cause.
• Use it to separate access, availability, data rules, and incorrect use.
• Use it before routing a problem to the right person.

Before you start

• Minimum information: the user, the Console area, the time, the message, and the goal.
• Confirm whether the problem affects one person, a group, or everyone.
• Reproduce it with a simple action where possible.

Step by step

1. Classify the symptom: an area does not appear, data does not appear, a query is denied, a query is slow, or the workspace is unavailable.
2. For an area that does not appear, review the usage role.
3. For data that does not appear, review the catalog and the data rule.
4. For a denied query, investigate the access decision.
5. For an unavailable workspace, check NoteCore and its visible status.
6. For a general problem, check module status and communicate the impact.
7. Record the conclusion and the next action.

What happens next

• Users get a clear, actionable answer.
• Managers know whether to adjust a rule, a group, or a role.
• Problems needing specialist help reach the right person with enough context.

Common errors

• Escalating with no message, time, or affected user.
• Creating broad access to work around a problem that was never investigated.
• Confusing a broad query's slowness with the product being unavailable.
• "An access rule already covers the same data set": another rule already covers that catalog, schema, and table. The message is about the data you chose, not about the person. The fix: use a Group (one rule, several members) or choose a different data set.

Good practice

• Use language the user can see.
• Document the likely cause and the action taken.
• After the fix, check with the affected user.

Next steps

• Following the settings visible in the Console
• Glossary