Practical evaluation guide · Updated 7 September 2026
In this guide
A supported asset CSV workflow
Use documented CSV contracts for assets, paused maintenance schedules and completed work history. Preview and resolve errors before committing. Export records to reconcile identifiers and counts. These file transfers are snapshots, not continuous spreadsheet synchronization.
Export operational records deliberately
Managers can export assets, work orders, inventory and the new operational datasets for production, vehicles, fuel, facilities and contractor service records. Export access remains available after trial expiry. Keep files in an access-controlled location and agree a retention period with the receiving team. A downloaded CSV is a snapshot and will not update when the source changes.
Set contracts for external reporting
Document the timezone, currency, meter unit and meaning of each status before combining files with another system. Join on stable identifiers, preserve source timestamps and avoid treating an empty field as zero. Reconcile totals against the application before circulating a report. OEE aggregation should weight the underlying production exposure rather than average percentages.
Use customer-controlled native connections
Samsara supports customer API tokens for mapped odometer and engine-runtime imports. Xero supports OAuth with a customer-registered Web app, explicit organization selection and draft purchase-order export. Manage both in Integrations. Additional hotel/PMS and PLC connectors require their own provider contracts; neither connector implies access to unrelated systems.
Define the maintenance decision the integration should support
A maintenance integration is useful when it moves the right evidence into a workflow that somebody owns. Connecting two applications is not the outcome by itself. A vehicle reading may support a usage-based plan; a purchase-order export may support a finance handoff; a CSV may establish the first reliable asset register. Each has a different source, destination and acceptance test.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Begin with one concrete question: what information is being re-entered, where does it come from and what should happen when it arrives? Identify the person who currently performs the task and the person who uses the result. This makes it easier to evaluate whether automation removes work, changes it into exception review or introduces a new operational dependency.
Keep the scope bounded. A successful odometer import does not prove that diagnostic faults, dispatch activity and fuel transactions are also connected. A draft purchase-order export does not imply invoice payment or stock synchronization. Describe the actual supported record and direction of transfer before deciding whether the connection meets the customer's need.
Distinguish snapshots from ongoing synchronization
A CSV export is a snapshot of records at the time it is produced. A later change in the source application does not update the downloaded file. This can be appropriate for migration, reconciliation or periodic reporting, provided the receiving team knows the file's date and purpose.
Ongoing synchronization requires additional decisions: how often updates run, which changes are eligible, how identities are matched and what happens after an error. Even a scheduled connection may support only one direction and a limited set of fields. Avoid using the word “sync” as a substitute for those details.
PreventiveHQ supports documented file workflows for assets, paused schedules and completed history, along with customer-controlled native connections for selected Samsara readings and Xero draft purchase orders. Evaluate each separately. The existence of one supported connector does not create a general integration layer for every system in the operation.
Write a compact data contract before setup
A useful contract records the source system, destination record, stable identifier, fields, units, timestamps, update direction and error owner. It should also state what is deliberately outside scope. This can fit in a small table for a pilot; it does not need to become a large technical specification before the team can test one record.
AI-generated editorial illustration; not a customer photograph or product screenshot.
For a meter connection, the contract might identify the provider vehicle ID, target asset code, selected statistic and compatible unit. For purchasing, it might identify the local order, destination organization, supplier contact and draft status. The exact fields differ, but both require a reliable identity relationship.
Have the people who use the data review the contract. A technically valid transfer can still fail operationally if a planner interprets the timestamp incorrectly or finance expects a document state the export does not create. Agreement on meaning comes before automation of movement.
Use stable identities instead of display names
Display names are convenient for people but can change or be duplicated. A provider vehicle name may resemble an asset name without being a reliable match. Supplier names can also vary across systems. Use the stable identifiers supported by each workflow and maintain the mapping deliberately.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Test one known record end to end. Compare the source identity, destination identity and relevant context such as site or organization. Do not approve a large mapping solely because the names look familiar in a dropdown. A wrong identity match can place accurate data on the wrong record, which is difficult to detect from the value alone.
Review mappings when equipment, providers or organizational arrangements change. A moved telematics device or retired asset can invalidate an originally correct relationship. Include the integration mapping in the operational change process rather than treating it as permanent configuration.
Verify units, currency and time conventions
A number without its unit can be misleading. Distance may be expressed in metres, kilometres or miles; runtime may use seconds or hours. The source field's documented representation determines the conversion. Confirm the destination unit and test a known example before allowing the result to influence maintenance scheduling.
Dates also need a defined meaning. A source event time, an import time and a document creation time are different facts. When combining exports, preserve the relevant timestamp and timezone context. Do not assume that two similarly named date columns describe the same event.
For commercial records, establish the currency and the meaning of amounts before reconciliation. A draft purchase-order line, a supplier bill and a payment can represent different stages of the process. Matching an amount does not prove that the documents have the same accounting or operational effect.
Prepare file imports as controlled batches
Use the documented template for the record being imported. PreventiveHQ's asset, schedule and completed-history flows have different columns and validation rules. A general maintenance workbook cannot be treated as interchangeable with all three schemas. Prepare the destination file from a reviewed source copy.
Preview the file, resolve errors and reconcile the mapped values before committing. Keep the batch name and source version in a simple log so another person can explain what was imported. If workspace conditions change after preview, revalidate using the supported workflow instead of assuming the earlier result still applies.
After import, compare identifiers and representative fields as well as counts. A correct total can conceal incorrect site mapping or a unit error repeated across every row. Use the asset migration guide, schedule import guide and work-history guide for the specific contracts.
Use Samsara for the supported reading workflow
PreventiveHQ's Samsara connector accepts a customer-controlled API token and supports mapped odometer and engine-runtime imports. The customer maps a provider vehicle to the intended maintenance asset and selects a supported statistic. The connector converts the supported value into a compatible asset unit.
The connection is intended to support maintenance usage evidence. It does not imply GPS dispatch, fuel-card ingestion, diagnostic trouble-code workflows or every data family Samsara offers. Review the selected field against Samsara's vehicle statistics documentation and test one vehicle whose reading can be independently verified.
Repeated, stale and lower cumulative readings are skipped by the supported ingestion flow. That behavior helps protect the asset record from duplicate or regressive updates, but the team still needs an owner for missing readings, mapping changes and counter replacement. Use the Samsara setup guide for the connection and pilot sequence.
Use Xero for the supported purchasing handoff
PreventiveHQ's Xero workflow uses OAuth through a customer-registered Web app. The customer selects the intended organization and provides the supplier contact identity needed for the export. The supported action creates a draft purchase order from the local purchasing record.
This is a defined document handoff, not a promise of complete accounting synchronization. It does not create an invoice-payment workflow, automatically match supplier bills or make the two applications interchangeable. Finance should review the draft in the destination system using its normal process.
Test with a small, clearly identified order and reconcile the destination organization, supplier, lines and document state. Repeated export behavior should be checked using the supported action rather than manually creating another order to compensate for uncertainty. See the Xero purchase-order guide for the current setup requirements and scope.
Keep customer credentials under customer control
The customer should create or authorize the provider access required for the connection. Use the permissions needed by the documented workflow and keep credentials out of shared spreadsheets, screenshots and support descriptions. Configuration should be performed by an appropriately authorized person in the customer's organization.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Know the difference between disabling a local connection and revoking provider-side access. Those actions may have different effects. For example, removing a local integration configuration should not be described as proof that every provider authorization has been revoked. Review the provider's own account controls when access needs to be withdrawn completely.
Assign ownership for credential changes. Tokens can be rotated and OAuth access can expire or be revoked. The team needs to know who can restore the connection and how to verify that it resumed correctly. A connection that depends on an unowned personal account creates an avoidable operational dependency.
Test retries and partial failures before relying on the flow
An integration should be evaluated under more than an ideal successful response. Repeated requests, temporary provider errors and invalid mappings occur in ordinary operation. The acceptance test should establish what the application preserves, what it reports and what the user should do next.
AI-generated editorial illustration; not a customer photograph or product screenshot.
For a reading import, inspect the asset after a repeated run and a stale value. For a purchase-order export, verify the behavior of repeating the supported export action for the same record. Do not assume that a generic retry button is harmless unless the workflow's duplicate protection has been demonstrated.
When a failure occurs, preserve enough non-sensitive context to investigate: the affected record, approximate time, selected source and visible error category. Avoid repeatedly changing several settings at once, because that makes it harder to identify the cause and can introduce a second problem while resolving the first.
Reconcile external reports with the application
Exports can support reporting, but combining them requires consistent definitions. Decide how statuses, dates and missing values will be interpreted before calculating metrics. An empty value should not automatically become zero, and a retired asset should not necessarily share the same exposure denominator as an active one.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Check totals against the application for the same scope and observation period. If the report filters by site, status or date, record those filters. A mismatch may come from different inclusion rules rather than an export defect. Make the comparison reproducible so another person can identify where the difference appears.
For OEE, aggregate the underlying productive contribution and planned production exposure rather than taking a simple average of percentages from unequal runs. The OEE guide explains the calculation and limitations. More generally, preserve the raw quantities needed to reconstruct a metric instead of exporting only its final percentage.
Treat calendar exports as deadline snapshots
PreventiveHQ's maintenance calendar export produces an ICS snapshot of work-order deadlines. The events are all-day deadline entries, not technician appointments or reserved work windows. Opening the linked work order remains necessary for the latest status and operational detail.
The downloaded file does not continuously update when work changes in PreventiveHQ, and editing an imported calendar event does not write the change back into the maintenance application. Explain that boundary to the people who receive the file so they do not treat an old calendar entry as the authoritative current schedule.
Test the export in the calendar application your team uses and verify dates under the intended timezone. Use the calendar export guide for the detailed behavior. A useful deadline view can support coordination while remaining distinct from a two-way scheduling integration.
Evaluate unsupported systems with a concrete requirement
If the operation depends on a hotel PMS, PLC platform, ERP or another provider, describe the required record and action precisely. “Integrate with our system” is too broad to assess. Identify whether the need is to read a measurement, create a document, update a status or retrieve historical evidence.
Check the provider's documented access method and the customer's entitlement to use it. An available public API does not establish that every desired workflow is supported by PreventiveHQ today. Keep the capability gap visible in the buying decision and define a bounded acceptance test for any proposed implementation.
Avoid treating a generic CSV workaround as equivalent to a live native connection. It may still be useful for a pilot or periodic reconciliation, but its cadence, manual effort and limitations should be explicit. The customer can then decide whether that process is sufficient for the current scale.
Run a one-record integration acceptance test
Choose one source record whose identity and expected values are known. Document the intended destination and result before connecting the systems. Perform the supported transfer, inspect the destination and have the operational owner confirm the meaning of the result.
Repeat the relevant duplicate or error case and verify that the record remains correct. Then test the maintenance action that uses the transferred data, such as reviewing due work or inspecting the exported draft order. This connects technical success with the customer's actual workflow.
Record remaining manual responsibilities, expected review cadence and the person who owns exceptions. Expand only after another team member can understand the configuration and evidence. The integration is worth adopting when the complete handoff is reliable, reviewable and maintainable by the customer.
A compact example integration contract
For an illustrative vehicle-reading pilot, the contract can state: one provider vehicle ID maps to one maintenance asset; the selected source is a documented cumulative runtime statistic; the destination uses hours; the source timestamp is preserved for freshness review; and the maintenance coordinator owns exceptions. The acceptance record then compares a known source value with the resulting asset value and confirms the intended due-work behavior.
For a purchasing pilot, the contract instead identifies the local purchase order, selected Xero organization, supplier contact and expected draft document. The reviewer checks lines and state in the destination. These two contracts should not share a vague “data synchronized” acceptance criterion because they support different business actions.
What should happen when the source record changes?
Determine whether the supported workflow transfers that type of change at all. A one-time export may not update an existing destination document, while a reading import may accept only newer compatible cumulative values. Test the actual action and record its limits. Do not manually repeat a transfer under a new identity merely to make the destination look current; that can create duplicate records and weaken reconciliation.
Who should approve expansion beyond the pilot?
The operational owner should confirm the result's meaning, while the person responsible for provider access confirms the connection remains appropriately controlled. Agree the review cadence and exception owner before adding more records. A technical success message is useful evidence, but the customer's approval should rest on the complete workflow and its ongoing maintenance burden.