Reference · built on requestOperator by FibricFleet, routes & field

Inspection Gap

Finds vehicles dispatched without a pre-trip inspection or with an open DVIR defect and proposes grounding the unit or assigning a repair.

Request accessPricing ↗

About

Inspection Gap compares every trip start with the inspection record for that vehicle and day. Samsara streams DVIRs with safetyStatus safe, unsafe, or resolved and defectIds; Geotab holds DVIRLog with logType PreTrip and isSafeToOperate and each DVIRDefect's repairStatus; Motive lists inspection_reports with status with_defects, with_signature_missing, or corrected. A vehicle that moved with no pre-trip log, or with a defect still NotRepaired, is a gap.

The job proposes what to do with the unit: a status change that grounds it in Fleetio, an issue or work order for the defect, and a swap so the route still runs. A fleet manager approves.

This is a reference listing. It documents what Fibric would read from Inspection Gap and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • DVIRs from Samsara through GET /dvirs/stream with safetyStatus, defectIds, vehicle or trailer, and authorSignature type driver or mechanic
  • Trip starts from Samsara's /trips/stream and Geotab Trip records, which say when a vehicle actually moved
  • Geotab DVIRLog with logType, isSafeToOperate, driver, and dVIRDefects, each with repairStatus NotNecessary, Repaired, or NotRepaired
  • Motive inspection reports through GET /v1/inspection_reports, filtered by status, with defects by area and category and mechanic_signed_at
  • Open issues and work orders on the vehicle in Fleetio through GET /issues and GET /work_orders
  • Which vehicle each route is assigned to: vehicle_id on a Route4Me route, or the worker's vehicle in Onfleet

Proposed actions

  • Target capability: propose grounding the unit by changing vehicle_status_id through PATCH /vehicles/{id} in Fleetio to the status you designate
  • Target capability: propose an issue through POST /issues with asset_id, asset_type Vehicle, summary, and reported_at, or a work order with line items
  • Target capability: propose reassigning the route to another vehicle through the Route4Me route's vehicle_id, or the Onfleet task's container
  • Target capability: propose a Slack message to the driver's supervisor through chat.postMessage naming the vehicle, the trip, and the missing or open inspection
  • Target capability: propose marking a Motive report corrected through PUT /v1/inspection_reports/{id} once the Fleetio work order closes

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch the unit that rolled before its pre-trip

    Compare each /trips/stream tripStartTime against the vehicle's last DVIR from /dvirs/stream. No safe DVIR that day means a gap; propose a Slack message to the supervisor and a Fleetio issue.

    With Samsara, Fleetio, Slack

  • Ground a unit with an unrepaired Geotab defect

    When a DVIRLog's dVIRDefects include repairStatus NotRepaired and the device has a Trip today, propose the Fleetio status change and a work order for the defect's part.

    With Geotab, Fleetio

  • Swap the route before dispatch

    If the flagged vehicle carries a Route4Me route for today, propose changing the route's vehicle_id to a unit with a safe inspection, in the same approval as the grounding.

    With Route4Me, Fleetio

  • Close the loop in Motive

    After the Fleetio work order for a with_defects report is closed, propose PUT /v1/inspection_reports/{id} so the Motive record shows corrected.

    With Motive, Fleetio

Requirements

  • Electronic inspections in the telematics system: Samsara DVIRs, Geotab DVIRLog, or Motive inspection reports
  • A maintenance system where a unit can be grounded and a repair opened: Fleetio
  • The route system that names which vehicle runs which route: Route4Me or Onfleet
  • Your rule for what counts as a gap: no pre-trip within a set time before the first trip, or any defect not marked repaired
Authentication
A Samsara API token with Read DVIRs and Read Trips, a MyGeotab API user with DVIRLog access, or a Motive API key with the Inspections Reports scope; a Fleetio API key with Account-Token; Route4Me or Onfleet keys; a Slack app with chat:write.

Limits

  • A paper inspection is invisible to the job; only electronic logs count, so a unit may be flagged that was inspected on paper
  • Samsara's stream is keyed by updatedAtTime; a DVIR edited later reappears and is re-evaluated
  • Geotab's isSafeToOperate is set when repairs are signed off; a defect list with no sign-off is treated as open
  • The job proposes grounding; the vehicle keeps moving until a person approves and the driver is told

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Inspection Gap ↗

Questions and answers

Who approves a grounding, and what do they see?
The fleet manager, or the role you name. They see the vehicle, the trip that moved it, the inspection record found or not found, the defects with repair status, the proposed Fleetio status, the issue or work order text, and the route swap if one is needed.
What is kept after the decision?
For each gap: vehicle, date, trip id, the DVIR or report id and its status, the defects, the rule that fired, every proposal, the approver, the time, and the Fleetio issue, work order, or status change ids. Rejected gaps are kept with the reason typed.
Can it stop a vehicle or override a driver?
No. It has no control over the vehicle. It proposes a status change in Fleetio and a message to a person. Whether the driver stops is a human decision; the job records what was proposed and when it was approved.
Ask about Inspection Gap

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy