QHSE Software Integration Claims: Why Most Are Conditional

"Integrates with your ERP" is the kind of line a QHSE software vendor's website may carry, and one of the hardest to turn into a plan. A logo wall shows that a connection exists somewhere. It does not show that it is included in the plan you would buy, works with the version of the system you run, or moves the data your process needs.

Our capability map counts what the research records say about ten capability families across 212 profiles. API and integrations is the family with the highest share of conditional-only profiles among those that reach it, and this article explains what that means for a buyer, which questions follow from it and how to test an integration during a trial.

The figures at a glance

The box below is built from the same generated file as the capability map. The sections that follow explain how to read each number.

What the records show

Each profile in our directory carries a list of capability statements, and each statement has a documentation status. Across all 212 profiles there are 2,449 statements, of which 1,296 (53%) are documented without a stated dependency and 1,044 (43%) are conditional. The rest are unverified or unsupported.

For integrations the balance is different. A total of 136 of 212 profiles (64%) have at least one documented or conditional statement whose title is about an API or integration. Of those 136, only 19 have a documented statement. The other 117 have conditional statements only, which is 86% of the 136. A further 12 profiles have only unverified statements, and 64 have no matching statement. The four groups add up to 212.

The pattern differs by category, though the categories are small. In Safety Management 7 of 12 profiles have a documented integration statement; in EHS Management it is 2 of 43. Read the gap as a difference in how the researched vendors describe themselves and how much of it we could confirm, not as a ranking of the categories. The capability map has the full grid and two CSV files.

What "conditional" means here

On this site a statement is conditional when the vendor's own pages describe the capability, but the record states a condition that decides whether a buyer gets it. The condition can be a plan or edition, a separate module or licence, a region, or a set-up the buyer has to demonstrate. Unverified means the research could not establish the capability from the pages it read, and it is not a claim that the product lacks it.

The conditions on integration statements recur. A keyword read of the scope notes, which is not a coded count, finds five kinds:

• Plan or edition. The API or connector sits in a higher tier, or in an add-on, and the entry plan does not include it.
• Separate licence or enablement. The capability exists but has to be requested, licensed or switched on for your account.
• Named systems and versions. A connector is described for particular systems, and the record does not establish that yours is among them.
• Objects and fields. A connection is documented, but which records and fields move across, and how changes and deletions are handled, is not stated.
• Who builds and runs it. The vendor, a partner or your own team does the work, and responsibility for support is not described.

None of these makes a statement false. They make it incomplete, which is the point: conditional is a distinct level of assurance, between "described and unconditional" and "not found". The trouble starts when a buyer reads "documented or conditional" as one number, because the two levels support different decisions.

Why integrations are conditional more often than other capabilities

Across the ten families we count, the share of conditional-only profiles among those that reach the family runs from 27% for document control (8 of 30) to 86% for API and integrations. The next highest are offline capture (76 of 117, 65%) and security and single sign-on (53 of 84, 63%). Reporting and dashboards stands at 46 of 130 (35%).

One reading is that an integration depends on a second system the vendor does not control, so the record may attach a qualifier more often. We have not tested that explanation, and the counts do not show why a statement was conditional. What they do show is that for integrations a plain "yes" is the exception in our records.

Two cautions keep the figure in proportion. The map counts statement titles: a record may describe an integration inside a statement with a different title, and that statement is not counted here. And a count of conditional statements measures how vendors document and how we recorded it, not how well any integration works.

Questions to ask about every integration

Put these in writing, and ask them of every vendor on the shortlist so the answers can be compared.

1. Which plan or edition includes it? Ask for the exact tier and for the line in the quote, not for a description.
2. Is there a separate licence, fee or usage limit? Include per-connector charges, call limits and partner licences.
3. Which systems and versions are supported? Name your ERP, HR, identity and document systems and the versions you run. The integrations ecosystem study and the article on named systems in integration statements show which systems the researched profiles name.
4. What data moves, in which direction, and how often? List the objects and fields, whether sync is one-way or two-way, and whether it runs in real time or in batches.
5. How are changes, deletions and missing fields handled? A gap here can break a mapping.
6. How does access work? Ask about authentication, the permissions the connection holds and who manages the keys. Some APIs use the OAuth 2.0 authorisation framework in RFC 6749, which lets one application obtain limited access to another without sharing user credentials; ask which method this one uses and what the connection can reach.
7. Who builds, runs and supports it? The vendor, a partner or your team, and what the support terms are for each.
8. How are changes announced? Ask how long before a change to the interface you will be told, and whether there is a test environment.
9. What is the security scope? An integration may sit outside the audited system of the main product. The article on SOC 2 and ISO 27001 explains how to ask.

The RFP template can carry these as written requirements, and our guide to QHSE software integrations sets out data ownership and acceptance tests for the handoff.

How to test an integration in a trial

A trial is a point where the claim can be tested rather than asked about, but only if the trial includes the integration. How often a trial is documented at all is the subject of our article on free trials. A workable test has seven steps.

1. Confirm the trial includes it. Ask whether the trial tenant has the API or connector enabled, and what plan it simulates. If it does not, ask for a time-limited enablement or a sandbox in writing before you start. If neither is possible, ask for a reference call with a customer who runs that integration on a similar version.
2. Choose one real flow. A single, specific flow, such as sending a closed action to a ticketing system or loading the employee list from your HR system, is more informative than a general check that the integration exists. Write down the fields and the direction.
3. Use realistic data. Take a small extract from your own system, including awkward cases: empty fields, long text, special characters, duplicates, records that change and records that are removed.
4. Test access. Set up the connection with the least privilege it needs, and note who holds the credentials, how they are rotated and what happens when they expire.
5. Test failure. Switch the receiving system off, or send an invalid record, and watch what the tool does: whether it retries, tells anyone, logs the error, or creates a duplicate on retry.
6. Reconcile. Count the records on both sides and compare a sample field by field. Decide who owns reconciliation after go-live.
7. Write the pass criteria before you start. For example: the flow runs on the entry plan, completes within an agreed time and leaves no unexplained difference. Mark the result as proven, partly proven or not proven, and keep the proof with the scorecard.

The demo checklist shows how to fit these tests into a two-week plan with a shared script, and the buying guide covers the wider evaluation.

Method and limits

The counts come from the capability statements in each profile's research record: 2,449 statements in 212 records. A statement belongs to the API and integrations family when its title contains one of these words: api, apis, integration, webhook, connector, connection, erp, data exchange or data flows. Only the title is read. A profile counts once per family, at its strongest status: documented first, then conditional, then unverified or unsupported. Records are as of 14 October 2026. The methodology describes the profile set, and the capability map lists the rule for every family and carries the CSV files.

This is documentation review, not hands-on testing: nobody here ran an integration. The profiles are the products we researched, not every QHSE product. Categories are small, so a percentage within one moves by several points per profile. No score, price or payment is an input, and nothing here ranks or recommends a product.

Disclosure. 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 in this article.

FAQ

Does a conditional integration statement mean the integration does not work?

No. It means the vendor's pages describe the capability but the record attaches a condition, such as a plan, a licence or a set-up. The condition is what you need to establish before relying on it.

Is an API the same as an integration?

Not quite. An API is an interface that lets another system exchange data with the product. An integration is a working connection between two systems, which may use that API, a prebuilt connector or an import file. A documented API does not, by itself, show that the connection you need exists.

Sources

• The QHSE Standard: Capability map 2026, the counts, keyword rules and CSV behind every figure
• IETF: RFC 6749, The OAuth 2.0 Authorization Framework, opened on 3 October 2026