Which systems QHSE software integrates with: what 209 profiles name

What the records show

1. Most profiles mention integration without naming a system. 57 of 209 (27%) name at least one system. 91 of 209 (44%) name no system but do name a standard or an interface type, most often an API. 39 of 209 (19%) mention integration, single sign-on or a type of system such as an ERP or an HR system and name nothing more, and 22 of 209 (11%) contain no integration mention that we found.
2. Which systems are named, and how many a profile names. The most often named systems are Power BI (18 profiles); Microsoft Entra ID, Azure AD or Active Directory (14 profiles); SAP (13 profiles); Microsoft 365 or Office 365 (9 profiles) and Okta (7 profiles). Among the 65 profiles that name a system or an identity standard, the median names 2, 27 name three or more and the most any profile names is 7.
3. Some kinds of system are named more often than others. Identity and single sign-on is named by 25 of 209 (12%) and ERP and finance by 21 of 209 (10%), against 2 of 209 (1%) for documents and e-signature. Where a record names only a type of system, such as an ERP, an HR system or a CMMS, it is counted as a mention and not as a named system: 29 profiles mention an ERP without naming one.
4. An API is the most common interface, and it is usually named without a system. 122 of 209 (58%) name an API of any kind, 26 a REST API, 31 CSV or XLSX files, 15 webhooks, 10 OData, ODBC or SQL access and 9 a no-code connector platform. 80 of the profiles that name an API name no system.
5. Most statements that name a system depend on a condition. Across 162 pairs of a profile and a named system or identity standard, 51 (31%) are in a documented capability statement, 95 (59%) only in conditional ones, tied to a plan, edition, add-on or set-up, and 16 (10%) only in other record text. Of the 57 profiles that mention single sign-on, 12 do so in a documented statement and 39 only in conditional ones. For an API, 25 of the 122 profiles that name one do so in a documented statement and 91 only in conditional ones.
6. The share naming a system varies by software category, in small groups. Among the 12 software categories with at least 5 profiles, the share naming a system is highest in Audits & Inspections (8 of 15, 53%) and lowest in Occupational Health (1 of 11, 9%). One profile moves a category of this size by several points, so read the counts and treat the spread as a pattern in this sample.

The gap: a named integration against an integration mentioned

Each profile falls in exactly one of four groups, read from the strongest to the weakest. A profile that names a system counts once, however many systems it names. The groups are defined by what the record names, so a profile that names only an API sits in the second group even when the vendor's integrations are not listed on the pages we read.

The distinction matters at shortlisting. A statement such as "an API is available" tells a buyer little about the system they need to connect, while a record that names a system leaves a specific question to test: which version, which direction, which records and which plan. A profile in the third or fourth group may still integrate with many systems; the record simply does not say, and the question belongs in the first call.

Systems and standards the records name

Each row of the dictionary below is counted as the number of profiles that name it. For each profile and row we keep the strongest status: documented when a documented capability statement names it, conditional when the strongest statement is conditional, which on this site means the vendor ties it to a plan, edition, module, region or set-up, and record text only when the name appears only in other text of the record, such as a feature list, an FAQ answer or a pricing note, and not in a documented or conditional capability statement.

Rows overlap: a profile that names SAML and also names single sign-on counts in both rows, and a profile appears in every row it names. A "system type" row counts a profile that mentions the type (an ERP, an HR system, a CMMS) in an integration context; it does not say which product. A statement that the record flags as not described, not found or planned is not counted.

By kind of system

The nine system categories group the dictionary rows. A profile counts in a category when it names at least one system or identity standard of that category, at the strongest status among them. The last column counts profiles that mention only a type of system in the category, with no product named, so that "ERP integration" is visible as a mention and not hidden.

Interface types

Interface types describe how data moves rather than which system it moves to. They are counted wherever a record names them, outside a sentence that says the item is not described. An "API of any kind" row includes the REST API row, and a profile can name several.

The interface types answer different questions. A REST API lets a customer or a partner read and write records through the vendor's published endpoints, and its documentation, authentication, rate limits and plan tier decide what is possible. Webhooks push an event to a URL when something changes. Scheduled file transfer and CSV imports suit batch exchange with a payroll, ERP or data-warehouse process. A no-code connector platform places a third-party service between two systems, which adds a subscription and a place where failures can occur.

By software category

The table uses the 12 software categories with at least 5 profiles, which together hold 180 of the 209 profiles. The other 12 categories hold 29 profiles between them and are pooled in the last row. A profile belongs to one category, the one shown in the directory.

How to read these numbers

• Naming a system is not proof of a working integration. A record may carry a name from an integrations page, a partner listing, a case study or a feature list. We did not run a connector, install an add-in or test a single sign-on set-up for any profile, so a count says how many records name a system, not how many integrations work.
• Plan and add-on conditions decide what a buyer gets. A conditional statement ties the capability to a plan, edition, module, region or set-up. The documented and conditional columns are two levels of assurance, and adding them hides the difference.
• A missing name is not a negative. A profile in the mention-only or no-mention groups may connect to many systems that its public pages do not list. The counts reflect what the vendor published and what our research recorded.
• A dictionary finds names, not meaning. The matcher reads words, so it can miss a system the dictionary does not list, and it can count a name used in a sense we did not intend. Statements about a platform a product is built on, such as a Salesforce-native product, are excluded for that platform; the same relationship can still appear for other platforms.
• Identity standards are not products. SAML, OpenID Connect, SCIM and LDAP are protocols that an identity provider speaks. A profile that names them has told you how sign-in works, not which provider it works with.
• Categories are small. Percentages in a category of five to twelve profiles are shaky. The categories are the directory's own, and a product that serves several is counted in one.
• These are counts of profiles, not of the market. The 209 profiles are the products we have researched, not every QHSE product, and a profile can name a system only if the pages we read name it.

What to ask when a profile names a system

1. Which product, version and edition of the named system does the connector support, and is it the version you run?
2. Which direction does data move, which records and fields move, how often, and which side is the system of record?
3. Is the connector included in the plan or edition you would buy, or sold as an add-on, a partner product or a services project? Put the answer in the quote.
4. For single sign-on: which protocol, which identity providers have been used in production, whether user provisioning is included, and on which plan.
5. For an API: is the documentation public, which objects can be read and written, what are the authentication method and rate limits, and who supports a customer-built integration?
6. Who monitors the connection, how are failures reported, and what happens to a record that fails to transfer?

The integrations guide covers how to scope a connection, and the RFP template and the demo checklist turn these questions into written requirements and demonstration tasks with your own system and test data.

Method: the dictionary, the rules and the limits

What is read

The text of each profile record: every capability statement (its title and explanation, with its status), every FAQ (question and answer), and the feature, strength and weakness lists, the pricing text, the description, tagline, fit and caution. Statements are read one sentence or clause at a time. Capability statements with the status unverified or unsupported are not read, because they say that the review could not establish the capability or that it is not provided. A sentence that holds a negation word (not, no, none, without, never, cannot, unconfirmed, coming, roadmap, planned, future) is not read, so "single sign-on is not described" does not count as naming single sign-on.

How a name is matched

A keyword matches the same run of words in lower case, whatever punctuation or spacing separates them, and only at word edges; a trailing * allows any ending. The phrases in the last column are removed from the text before the keywords are tried. A system or a system type is counted only in an integration context: the sentence, or the title or question that heads its statement, must also hold one of these words: integration*, integrate, integrates, integrating, connect, connects, connecting, connection*, connector*, api, apis, webhook*, sync, synchroni*, sso, single sign-on, saml, oidc, scim, ldap, interface*, import*, export*, upload*, feed*, plugin*, add-in*, gateway, middleware, bridge. A standard or an interface type is counted wherever it is named. A name is not counted for a profile whose own name or alias matches one of the keywords, so a SAP product does not count as naming SAP. A profile is placed in the "mention" group when a sentence holds one of: integration*, integrate, integrates, integrating, connector*, api, apis, webhook*, sso, single sign-on, saml, oidc, scim, ldap, ipaas.

Counting rules

• A profile counts once per dictionary row, at its strongest status: documented first, then conditional, then record text only. The status comes from the capability statement that holds the name; a name found only outside capability statements is record text only.
• The four groups are exclusive and read in order: names a system; otherwise names a standard or an interface type; otherwise mentions integration, single sign-on or a system type; otherwise none.
• The category of a profile is its own category, or the catalogue category where the profile has none. Percentages are rounded to whole numbers. Records are dated up to 3 October 2026.
• No score, rating, price or payment is an input, and the page does not rank or name any product. The profile set is described in the methodology.

Limits. This is documentation review, not hands-on testing. A system that the dictionary does not list is not counted, and the table above shows which rows are empty. Matching is by words, so a keyword can occasionally catch a sentence we did not mean, and a system described in other words is missed. Records change; the CSV files are regenerated with them.

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, it is counted in every figure above like any other profile, and it is not named on this page.