Named Systems in QHSE Software: What 209 Profiles Say

A vendor page that says the software "integrates with your ERP" gives a buyer a reason to ask a question and little else. A page that names the ERP, the identity provider or the reporting tool gives a more specific claim to check. We went back through the research records of our profiles to count how often a record does the second, and how often it only does the first.

A total of 57 of 209 profiles (27%) name at least one system in a statement about integration. This article gives the counts from our integrations ecosystem study, explains the difference between a named system, a named standard and a bare mention, and sets out how to turn each one into a requirement you can test.

The figures at a glance

The box is generated from the same data file as the study page, and each number in it is explained in the sections below.

What the records show

Every profile is placed in one of four groups, ordered from the most specific record to the least specific. A total of 57 of 209 profiles (27%) name at least one system. A further 91 of 209 profiles (44%) name an identity standard or an interface, most often an API, but no system. Another 39 of 209 profiles (19%) speak of integration or sign-on in general terms, or of a system category such as ERP, and name nothing more. The last 22 of 209 profiles (11%) contain no integration mention that we found. The four groups add up to 209.

Taken together, 130 of 209 profiles (62%) mention integration or an interface type without naming a system. That says little about the product either way. The line "an API is available" is too general to test, because it does not say which system a buyer's data would reach.

Of the 65 profiles whose records name any system or identity standard, the median profile names 2, 27 name three or more, and the most that any one names is 7. These count dictionary rows, and one row can cover several product names. The systems named most often are Power BI (18 profiles), Microsoft Entra ID, Azure AD or Active Directory (14), SAP (13), Microsoft 365 or Office 365 (9) and Okta (7). The Microsoft 365 row also counts Outlook and OneDrive. These are counts of records that carry the name. They do not rank the systems, and the dictionary behind the study decides which names can be found at all.

Which kinds of system are named

Grouping the dictionary into nine kinds of system puts identity first: 25 of 209 profiles (12%) name an identity standard or provider. ERP and finance systems follow at 21 of 209 (10%), then productivity and collaboration tools at 19 of 209 (9%) and BI and data platforms at 18 of 209 (9%). At the other end, 5 of 209 profiles (2%) name an HR or payroll system and 2 of 209 (1%) name a document-storage or e-signature service.

A name and a type are counted differently. Where a record mentions an ERP and names no product, it counts as a mention only: 29 profiles are in that position for an ERP, and 21 for an HR, payroll or learning system. A buyer with a particular ERP cannot read from those records whether it is covered, and has to ask.

The share naming a system also differs by software category, among the categories with at least five profiles. It runs from 8 of 15 profiles in Audits & Inspections (53%) to 1 of 11 in Occupational Health (9%). Because a category holds between 5 and 43 profiles, a single changed record shifts its percentage noticeably. The spread is a pattern in this sample, not a trait of a type of software.

What a conditional statement means for a named system

Each named system or standard is read from the statements in a profile and given the strongest status among them. The study counts 162 pairs, each one a profile together with a named system or standard. Of these, 51 (31%) sit in a documented capability statement, 95 (59%) only in conditional ones, and 16 (10%) only in other record text. A conditional statement depends on something the buyer has to confirm: a plan, an edition, an add-on, a region or a set-up. Record text only means the name appears in a feature list, an answer to a question or a pricing note, with no capability statement behind it. The three levels support different decisions, so adding them hides the difference.

Single sign-on, which the dictionary counts as a type and not as a named system, shows the pattern. A total of 57 profiles mention it: 12 of the 57 in a documented statement, 39 of the 57 only in conditional ones, and the other 6 in record text only. For an API of any kind, 25 of the 122 profiles that name one have it in a documented statement, and 91 of the 122 only in conditional ones.

Read these as a description of how the records are written, not of how any product behaves. Our article on conditional integration claims counts a different unit, the titles of capability statements in the capability map, so the two sets of figures are not interchangeable.

Interface types are named more often than systems

A total of 122 of 209 profiles (58%) name an API of any kind, against 57 of 209 (27%) that name a system, and 80 profiles name an API without naming any system. After the API come CSV or XLSX files (31 profiles), REST APIs (26), webhooks (15), SOAP, GraphQL, XML, JSON or EDI messages (11), OData, ODBC or SQL access (10), no-code connector platforms (9), SFTP or FTP (4) and MCP (2).

An interface type describes how data could move, not which system it moves to. An API describes a way in; whether your system is already on the other side depends on what has been built on it, by whom, and on which plan. SAML, OpenID Connect, SCIM and LDAP are similar in this respect. They describe how a sign-in or a user list is passed on, so a profile that names one has not named a provider.

From a named system to a requirement

Treat a name in a record as a lead and write it down as one. For each system that matters to you:

• Name your own version. Record the product and edition you run, and ask which versions the connection covers.
• Say what moves. List the records and fields, the direction (one way or both) and how often.
• Ask where it sits in the quote. A connection can be included in a plan, sold as an add-on, offered through a partner or delivered as paid services work, and the answer belongs in writing.
• Ask who builds and supports it. The vendor, a partner and your own team can each carry a different obligation when it fails.
• Test one real flow. Use your own data in a trial and record the outcome as proven, partly proven or not proven. Our article on free trials covers whether a trial is offered at all.

If a record gives only a type of system, ask the vendor for the list of products in writing, and do not read the absence of your system from a record as a no. The integrations guide covers scoping and acceptance tests, the RFP template carries these questions as written requirements, and the demo checklist fits the test into a scripted plan.

Method and limits

The study reads the text of each profile record one sentence at a time against a published dictionary of 50 rows: systems, identity standards, types of system and interface types. A system or a type of system counts only in a sentence that is about integration. A sentence with a negation or a planned feature is skipped, capability statements that the research marked unverified or unsupported are left out, and a profile's own name is not counted as a system it integrates with. Each profile counts once per row, at the strongest status found. The records used here were checked through 3 October 2026, and the methodology explains how the profile set was chosen. The study page lists every keyword and carries two CSV files, one with a row per dictionary entry and one with a row per profile.

Three limits apply. These are vendors' public statements and our reading of them, not tests: nobody here installed a connector or set up a sign-in. Documented is not the same as available, because a documented statement says what a page describes and not that the plan you would buy includes it. And silence is not absence: a dictionary finds the names it lists and misses a system described in other words, so a record that names no system may describe a product that connects to many. The 209 profiles cover the products we researched and not the whole market. Scores, prices and payments play no part in the counts, and the article does not rank or recommend any product.

Disclosure. One of the 209 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 named system mean the integration works?

No. A name in a record shows that the record, or a source it cites, mentions the system. It does not show that the connection is included in a plan, supports your version or has been run by anyone here. The statuses in the study separate a documented statement from a conditional one and from other record text.

What does it mean when a record names an API but no system?

It means the record describes a way for other software to exchange data with the product and names no system that our dictionary holds. That describes 80 profiles. The question for the vendor is which systems have been connected to it and who maintains each connection.

Should I rule out a product whose record names no system?

Not on this evidence. 130 of 209 profiles (62%) mention integration or an interface type without naming a system, and a record reflects what the pages we read published. Ask the vendor for the list and test the connection you need.

Sources

• The QHSE Standard: Integrations ecosystem 2026, with the keyword dictionary, the counts and two CSV files
• The QHSE Standard: Capability map 2026, which sets out the capability families and the status of each statement