# Report a problem usefully A report that gets answered in minutes says which account it happened on, on which screen, at what time, to which record, what you expected, what happened instead, and — the part almost nobody includes — what Connect did complete before it stopped. Screenshots help; timestamps and record identifiers help more. - **Status:** Available - **Audience:** both - **In the app:** #/activity, #/autonomy-audit - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/how-to/report-a-problem/ ## Capture these eight, in this order 1. **Which account.** The Owner workspace or a customer workspace. This single line eliminates the largest class of causes on its own. 2. **Which screen or route.** Name it as it appears in the address bar, not by description. 3. **When.** Date, time and the time zone you are in. 'This morning' costs somebody an hour of searching. 4. **Which record.** The conversation, call, prospect or deal — its identifier, not the customer's name. 5. **What you expected.** One sentence. 6. **What happened instead.** One sentence, and the exact wording of any message on screen. 7. **What Connect did complete.** The half that gets left out. A reply drafted but not sent is a different fault from nothing happening at all. 8. **Whether it repeats.** Once, every time, or intermittently. Intermittent is a real answer and worth saying. ## Why the account line matters so much Connect is one codebase serving two audiences, and a customer session takes a different route to the same capability: a customer's requests are rewritten to the tenant path, and anything the rewriter does not recognise becomes a refusal. Separately, an allowlist in the middleware refuses any path a customer session is not permitted to call. So 'it works for me and not for them', or the reverse, is a specific and very common shape of fault with two likely causes — and naming the audience puts an investigator straight onto them. A report that omits it starts with somebody guessing which of two paths to read. > **Note** If you can, check the other audience before reporting. 'Works on the customer workspace, refused on the Owner one' is worth more than a paragraph of description. ## The two things people leave out **What was completed** — Almost every failure here is partial. A message was drafted and not sent; a call connected and produced no summary; an import created rows and dropped some. Saying where it got to halves the search. **The Decision Log entry** — It records what was decided, by what, under which rule, and what happened — including refusals, because a refusal is a decision. If the problem is Connect not doing something, this is usually the entire answer, and it is often faster to read it than to write the report. Reading the log first is not a way of avoiding the report. It frequently turns 'Connect is broken' into 'Connect refused under a rule I did not know was set', which is a different question with an immediate answer. ## What not to include - Credentials of any kind. Provider credentials are sealed on save and never shown back to a screen, so nothing on your screen should be a secret — if something looks like one, that is itself the report. - The full text of a customer's message, when the record identifier will do. - A diagnosis. Say what you saw; a confident wrong theory in a report sends the first hour in the wrong direction. - A screenshot as the only evidence. It cannot be searched, and it usually crops out the time. > **Careful** If the problem is that something was sent to the wrong person, say so first and plainly. That is a different urgency from a screen not loading, and it should not arrive on the fourth line of a long report. ## Before you send it 1. Reload the screen once and see whether it recurs. - Result: A one-off that never returns is worth reporting differently from something reproducible, and you have just established which it is. 2. Check whether the same action works elsewhere — another record, another channel, another line. - Result: That distinguishes a broken capability from one broken record, which are fixed in completely different places. 3. Check the health endpoint if screens are failing generally. - Result: A service-wide problem and a screen-specific one look identical from one browser tab. 4. Read the troubleshooting page closest to the symptom. - Result: Several of the common faults have documented causes and a fix you can apply without waiting for anybody. ## Questions ### How do I find the identifier of a record? It is in the address bar when the record is open, and in the Data grid alongside the row. Either is better than the customer's name, which may match several people until duplicates are merged. ### Is a screenshot useless? No, but it is a supplement. It shows layout problems that words describe badly. Pair it with the time and the record identifier so it can be matched to what the records say happened. ### What if I cannot tell whether it is a fault or a setting? Report it anyway, and say that. A large share of reports turn out to be a rule working as designed — the useful outcome there is that the rule gets explained or changed, which does not happen if nobody says anything. ## Related - [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/) - [Find out why Connect did something](https://connectbyjbrh.com/docs/how-to/audit-a-decision/) - [A screen returned 403](https://connectbyjbrh.com/docs/troubleshooting/403-on-a-screen/) - [Connect appears to be doing nothing](https://connectbyjbrh.com/docs/troubleshooting/nothing-is-happening/) - [One product, two audiences](https://connectbyjbrh.com/docs/product/owner-and-customer/) - [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/) - [The customer facade](https://connectbyjbrh.com/docs/security/customer-facade/) ## What this page is based on - Connect source pack: overview (docs-source/sources/GENERAL.md §1 and §2 — two audiences and the request path) - Connect source pack: overview (docs-source/sources/GENERAL.md §10 — security and the health endpoint) - Connect capability registry (docs-source/facts.py — audit_trail, PRODUCTION)