Offline Support in QHSE Software: What the Records Show

Offline use is a common question from field teams, and in our records it is classified for a minority of profiles. Of the 212 QHSE, EHS and ESG software profiles researched on this site, 93 carry an offline classification: 40 are documented as working offline, 52 partly, and 1 needs a connection for the workflow that was assessed. The other 118 are not yet classified, which says something about how far the review has got and nothing about those products.

This article reads those figures with the capability map and the security, trial and offline study, explains what each label does and does not promise, and ends with a field test you can run before you sign.

What the offline labels mean

The directory sorts every profile into one of five offline groups, and the same groups drive the offline filter in the solutions directory.

• Documented offline workflow. The reviewed vendor pages describe an offline workflow for the use that was assessed. The assessed use is narrow and can be a single task such as completing an inspection on a phone.
• Partial offline workflow. Some functions work without a connection and others do not. The classification says "some", so you still need to know which.
• Connection required for the assessed workflow. The pages reviewed show the assessed task needing a connection. It is a finding about one workflow, not a verdict on the product.
• Not applicable. One profile, a document-template product, where offline use is not a meaningful question.
• Not yet classified. The profile has not been through the offline review, or the pages gave nothing to classify. This is a statement about our coverage.

The words "documented" and "partial" describe the vendor's published pages as read by the review. Nobody here ran the product on a device with no signal, so none of these labels is a test result.

How many profiles are classified

Counting the groups gives the picture below. The unclassified group is the largest, at 118 profiles or 56% of the set, and every offline figure in this article is therefore a figure about the 93 classified profiles, not about the market.

Among those 93, partial is more common than documented: 52 against 40. That order matters for buyers. A shortlist filtered only on the word "documented" leaves out the larger group, and a shortlist that treats the two as equal overstates what the partial group promises.

Why partial is the biggest group

A partial classification can cover quite different things. Capture of a prepared form on a phone may work offline while the screen where you design the form does not, or while a browser version of the same product needs a connection. In several of the classified records the scope note lists exactly these exclusions, along with conditions such as downloading content first, signing in before leaving coverage, or accepting that drafts wait on the device until they sync.

What the label cannot tell you is whether your task is on the working side of the line. An inspector who fills in a checklist and takes photos may be fully served, while a supervisor who must approve a permit on site may not be. Use the partial label as a prompt to ask which functions are excluded, then compare that list with the work your people do without a signal.

Category differences from the capability map

The classification is one view. The capability map is another: it counts the profiles whose research record contains a capability statement with an offline-related title, and sorts each statement as documented, conditional, unverified or unsupported. On that count, 117 of the 212 profiles (55%) have a documented or conditional offline-capture statement. Of those, 41 have a documented one and 76 only conditional ones, which means the record ties the capability to a plan, an app, a preparation step or a set-up. Another 30 profiles have only unverified or unsupported statements and 65 have none that match.

The two views differ in method, so they do not need to agree profile by profile, but they point the same way by category. The capability map's offline column rises and falls with what the software is for:

• Audits and inspections: 16 of 16 profiles (100%).
• Construction safety: 7 of 7 (100%).
• QHSE management: 15 of 17 (88%).
• Asset management: 6 of 7 (86%).
• EHS management: 33 of 43 (77%).
• Quality management: 7 of 22 (32%).
• ESG and sustainability: 3 of 30 (10%).

Tools built to take a checklist to an asset, a building site or a plant sit at the top. Tools built to consolidate emissions, supplier and disclosure data sit at the bottom, which may reflect that much of that work is done at a desk rather than at the asset; the counts do not test that. A buyer in the second group should not read the 10% as a weakness, and a buyer in the first should not read the 100% as a guarantee. It means every profile in that category has at least a conditional statement.

Coverage differs by category too. In the directory classification, 15 of the 16 audits and inspections profiles are classified and 3 of the 30 ESG profiles are. The classified group therefore leans toward field-capture products, and the 93 should not be treated as a representative slice of the whole directory.

What "documented" does not tell you

A documented workflow is a promising start. It leaves open the questions that decide whether it works in your building:

1. Preparation. Do forms, checklists, maps or asset lists have to be downloaded before the user goes offline, and who triggers that?
2. Sign-in. Can a user who has never logged in on the device work offline, and does a stored login expire after a set period?
3. Content. Are photos, signatures, voice notes and barcode scans included, and is there a size or count limit?
4. Scope. Does the offline mode cover the mobile app only, or the browser version too?
5. Approvals. Can a record be approved, closed or issued offline, or only captured and sent later?
6. Conflict handling. If two people edit the same record offline, what does the system do when they reconnect?
7. Data on the device. What is stored locally, how is it protected, and what happens if the device is lost before it syncs?

The scope notes of several classified records carry caveats on these very points.

A field test a buyer can run

Run the same test for every vendor on your shortlist, on a device your own staff use, with your own form rather than a demo template. Allow about two hours.

1. Prepare. Ask the vendor for a trial account, load one real checklist or permit, and note what the app downloads and when. Write down the steps the vendor says are needed before going offline.
2. Go offline for real. Switch on airplane mode, and keep Wi-Fi and mobile data off. A weak signal is a different test, so run that later.
3. Complete the work. Fill in the whole form, add two photos, a signature and a free-text note, and raise a corrective action if your process needs one. Try to edit a record you opened earlier.
4. Test the edges. Close the app, restart the device, and open the draft again. Leave it overnight if the vendor says access lasts a set time.
5. Reconnect. Turn the connection back on and watch what syncs, in which order, and how long it takes. Check that photos, signatures and timestamps arrived, and compare the recorded time with the real time.
6. Create a conflict. Edit the same record on two devices while both are offline, reconnect them one at a time and record what each user sees.
7. Write it down. Score only what you observed. Anything the vendor described but you did not see stays open on your scorecard.

The offline inspection apps guide walks through a longer version of this demonstration, the mobile QHSE software guide covers the wider app question, our article on audit trail and document control gaps describes how audit trail and document control differ and includes a step for testing an obsolete document on a device, and the demo checklist gives you a place to record the results. If offline use is a must-have, put the seven questions above into the RFP template so every vendor answers in writing.

How to cite these figures

Say what was counted. "40 of 212 researched profiles have a documented offline workflow, and 93 have been classified" is accurate. "19% of QHSE software works offline" is not, because it treats unclassified profiles as negatives and the researched set as the market. When you quote the capability map, name the status: "117 of 212 profiles have a documented or conditional offline-capture statement" is a count of statement titles in research records.

Browse the classified profiles with the documented and partial filters, and open any profile in the directory to see the scope notes behind its status.

Method and limits

The offline classification is the one the directory uses, and the counts come from the generated study data: 40 documented, 52 partial, 1 connection required and 1 not applicable, with 118 not yet classified, out of 212 profiles. The capability map counts the capability statements in each profile's research record, grouped into ten families by a published keyword rule on the statement title; offline capture is one family. A profile counts once per family, at its strongest status. Records were checked through 14 October 2026.

Limits that matter when you use these numbers:

• Documentation review, not hands-on testing. Statuses record what vendor pages say and what the review could confirm.
• The classification is incomplete. More profiles will be classified, and the groups will change as they are.
• The profiles are the researched set. They were chosen for research by this site and are not a census of vendors.
• Titles, not text. The capability map reads statement titles, so a profile that describes offline use under a different title is not counted in that family.

One of the 212 profiles belongs to a vendor that pays for sponsored placement on this site, and the editor works at that vendor. Its record was read by the same rules as every other and is counted in every figure above like any other profile; it is not named here. See the methodology for the full disclosure and the datasets page for downloads.