Getting help
Prepare a support report with scope, run or proposal identifiers, expected versus actual results, exact diagnostics and version information.
A useful issue report lets another person locate the exact operation and compare what you expected with what happened. Gather the details below without sharing credentials or private source records.
Before reaching out
- Start with the failing feature: pipelines, endpoint connections, ontology and queries, predictions, API errors or skill application.
- Reproduce once more and note what changed since it last worked. For external writes with uncertain effects, reconcile state before another execution.
What to include
A report with these five things gets solved fastest:
- Workspace and project: names and IDs for the affected scope.
- Run or proposal link: the exact run, proposal, or page — IDs beat descriptions. Quote record and run identifiers shown in the UI.
- Expected vs actual: what you expected, what happened instead, in one sentence each.
- Evidence: the relevant error text, validation message, or evidence chain — not a paraphrase of it.
- Recency and versions: when it last worked, the saved plan or forecaster version, query release, and relevant input cutoff. Include changes to connections, mappings, or skills.
Remove credentials, bearer tokens, API keys, and private source data from the report. Include connector counts or an exact diagnostic instead where possible.
While you wait
- Do not silently rerun structural failures; each unexplained rerun buries the evidence.
- Keep the workspace state intact — the run history and evidence links are what gets inspected.