# Omnitracs integration: hours of service and macros > Omnitracs feeds Roadmark hours of service and the macro messages drivers already send, so planning and the load's message thread use current data. URL: https://roadmark.ai/integrations/omnitracs Language: en Last updated: 2026-10-01 **TL;DR:** Roadmark reads hours of service and macro-based driver messages from Omnitracs. Hours of service tell dispatch planning how much of a driver's day is left, and a macro message a driver sends from the terminal lands on the load's own thread instead of a separate screen. ## What syncs One row for each kind of record: which way it moves, and when. | What | Direction | When | | --- | --- | --- | | Hours of service | Omnitracs to Roadmark | Every few minutes | | Macro-based driver messages | Omnitracs to Roadmark | When a driver sends one | ## Setting up Omnitracs 1. **Connect Roadmark to Omnitracs:** An admin connects the two accounts, so Roadmark can read hours of service and macro-based driver messages for the fleet. 2. **Choose what syncs:** Turn on hours of service and macro messages, or leave either off. 3. **Test with a real load:** Run one load through it and check that the hours a driver has left, and a macro message from the cab, both show up correctly before turning it on for everything. ### Before you start - An Omnitracs admin who can authorize the connection. A driver's hours of service and the macro messages they send from the cab both go through Omnitracs before Roadmark reads either one. Hours of service feed dispatch planning the same way any connected ELD's does: a plan never puts a driver on a load their remaining hours won't cover. The macro messages are the more distinctive half of the connection. ## What a macro message is On the driver's in-cab terminal, Omnitracs calls macros "canned messages," and its own [glossary](https://customer.omnitracs.com/help/qtracsWeb/help/en_US/procedural/glossary.htm) defines a macro as a message "formatted ahead of time so the driver or QTRACS user need only fill in the blanks." A dispatcher composing one [picks the macro from a drop-down list instead of typing freeform text](https://customer.omnitracs.com/help/qtracsWeb/help/en_US/procedural/msgsend.htm), and only the fields that change, a stop number or a status, are filled in and sent. It's a faster, more structured message than a text, built for exactly the short, repeated updates a load generates. ## Where it shows up in Roadmark Hours of service sit on the same unit card as trailer and home time that every connected ELD feeds, so dispatch planning checks one place regardless of which ELD a fleet runs. A macro message a driver sends from an Omnitracs-connected cab lands on that load's own message thread, the same place a message sent from [Roadmark's driver app](https://roadmark.ai/driver-app) would appear. For a fleet whose drivers stay on Omnitracs' terminal rather than switching to Roadmark's own app, that means dispatch still reads every update on the load, without opening a second screen to see what a driver sent from the truck. Location and hours of service from a connected ELD are also one of five sources [tracking](https://roadmark.ai/tracking) checks for a load's status, alongside the driver app, a carrier's own app or an EDI 214, visibility networks, and a check call when nothing else is reporting. ## A Tuesday example On the [carriers](https://roadmark.ai/carriers) board, unit 231 (A. Brandt) is on the board for Tuesday's run. With Omnitracs connected, A. Brandt's hours of service sit on unit 231's card the same way any connected ELD's would, so dispatch planning checks one place before assigning the unit's next load. If A. Brandt sends a macro from the terminal, a delay code at a stop, say, instead of typing it out, it lands on that load's own message thread straight away. Dispatch reads it there, next to any message a driver on Roadmark's own [driver app](https://roadmark.ai/driver-app) would have sent for a different load, rather than switching to a separate terminal view to see what came in from the cab. ## Running Omnitracs alongside the driver app A carrier doesn't have to move every driver onto Roadmark's driver app at once to get this. A unit whose driver stays on Omnitracs' terminal still shows up with current hours of service and a message thread that fills in from macro messages; a unit switched to Roadmark's driver app gets its messages the same way, just typed on a phone instead of picked from a terminal list. Dispatch works one board either way. For a fleet already running Omnitracs, the change is mostly what catches up downstream: a plan that respects the hours actually left on a driver's clock, and a macro message that reaches the load's own thread instead of staying on a terminal dispatch has to check separately. ## Questions about Omnitracs and Roadmark ### What does Roadmark read from Omnitracs? Hours of service and macro-based driver messages, the same two the Omnitracs integration is listed for in the directory. ### What is a macro message? A predefined message a driver picks from the terminal instead of typing freeform text, so only the details that change, such as a stop or a status, need filling in. Omnitracs' own documentation describes a macro as a message formatted ahead of time so the driver only fills in the blanks. ### Does a macro message replace the driver app's own messages? No. If a driver's cab is on Omnitracs rather than Roadmark's driver app, their macro messages land on the load's own message thread, the same place a driver app message would, so dispatch isn't checking two screens for one load. ### Does connecting Omnitracs change dispatch planning? Hours of service come from the connected ELD every few minutes, so a plan never sends a driver somewhere their remaining hours won't cover, whichever ELD is connected. ### Do drivers need to do anything differently in Omnitracs? No. A driver keeps sending hours of service and macro messages from the same terminal; Roadmark reads what's already there. ## Related pages - [Tracking](https://roadmark.ai/tracking): The few loads that need you, with reasons - [Asset carriers](https://roadmark.ai/carriers): Fleets that plan, dispatch and settle - [Driver app](https://roadmark.ai/driver-app): Stops, documents and pay on the phone - [Billing and settlements](https://roadmark.ai/billing): Invoices, driver pay and carrier pay - [Samsara integration: hours of service and ETAs](https://roadmark.ai/integrations/samsara): Samsara feeds Roadmark hours of service, location and engine data every few minutes, so tracking ETAs, dispatch planning and detention all use current data. - [Motive integration: hours of service and DVIR](https://roadmark.ai/integrations/motive): Motive feeds Roadmark hours of service, location, inspections and diagnostics, so tracking, dispatch planning and detention billing use current ELD data. - [Geotab integration: location, fault codes and idle time](https://roadmark.ai/integrations/geotab): Geotab feeds Roadmark GPS location, engine fault codes and idle time, so tracking's ETA, a unit's card and dispatch planning all use current data. Companies, people and shipment figures in product examples are fictional. They illustrate workflows and are not customer testimonials or measured results.