Skip to main content
Every report started in the reporter app, with its status and its delivery to the maintainer’s system. The Swedish label is Skaderapporter, under the Skaderapportering section of the sidebar.

The list

The grid filters on status, delivery status, vehicle and reporter, and searches title, description and vehicle number.

Report lifecycle


Detail

Clicking a row opens the report: description, asset, classification, diagnostic codes, and the delivery record. Open defect opens the defect row the report created.

Retry

A delivery that is pending or failed, and has no external identifier, can be retried. Retry resets the attempt count and delivers once, immediately. It is refused when the report has already been delivered or an attempt is running.

Transcript

The Transcript tab shows the whole conversation: the reporter’s messages, the assistant’s replies, and every direct edit made on the report sheet.

Submitted reports become defects

Submitting a report writes a row in the defect table straight away, so the fault appears on Defects and in the KPIs before it reaches the maintainer. The row is identified by external_system_id = APP- followed by 12 hexadecimal characters. When the maintainer’s system accepts the report and returns its own identifier, the row’s external_system_id is replaced by that identifier. From then on the maintainer’s daily defect file updates the row like any other imported defect, because the import matches on external_system_id within the project: closing date, cause and action arrive through the import.
The import overwrites the row only when the file’s external_updated_at is later than the time of delivery, which is when the row was last written.
With no maintainer integration enabled, reports are delivered to the log adapter, which returns no identifier. The defect keeps its APP- identifier and no import ever matches it.

Tables

Field reference

reporting_defect_report, reporting_report_session, reporting_report_message and integrations_outbound_sync.

Roles