The connector catalogue, and what a listing actually promises

The catalogue is the list of third-party systems Qorionix can connect to. This article explains what a row in that list is claiming, what it is not claiming, and how to read the status marker that appears on every one of them. It is worth ten minutes before you plan any work around an integration, because the difference between available and planned is the difference between a feature and an intention.

Our published claims page says we will never advertise a number like 700+ integrations, and will instead show a catalogue with available, beta or planned marked on every row. This article is that promise written out in full. It is deliberately unflattering about how short the list is.

How many rows there are, and what they are

There are 36 entries today. The number is computed when the platform starts rather than typed into a file, so it cannot drift away from the code behind it. Of those 36: 24 are available, 3 are beta, and 9 are planned. Every catalogue response the interface receives carries those counts alongside the rows, so a screen listing the catalogue cannot avoid telling you how many of the rows actually work.

The rows come from three different places, which is worth knowing because it explains why some entries behave differently from others.

Registered connectors (8)

Code we wrote that talks to a specific provider: entra_id, google_workspace_directory, slack, msteams, pagerduty, jira, servicenow and webhook. A connector in the registry is a promise that configuring it and health-checking it do something real. There is a test that fails the build if a connector with planned status is ever registered.

Template-driven applications (20 new rows)

Metadata describing how to wire an application to Qorionix's single sign-on or inbound provisioning — Box, Salesforce, GitHub Enterprise Cloud, Zoom and so on. These are not connectors. They are configuration recipes consumed by the SSO and provisioning engines. One of the 21 templates, Slack, merges onto the connector of the same name, so Slack is a single row offering notification, sign-on and provisioning rather than three separate rows.

Planned entries (9)

Rows with no code behind them at all. They are on the list as a roadmap statement, and the interface says so. A planned entry is only added when nothing real already occupies that identifier, so a roadmap note can never quietly downgrade a working integration.

The three statuses, in the product's own words

The status field is described in the source as the most important field in its file. These are its exact definitions:

The rules around the status text are enforced by tests rather than by good intentions. A row that is not available must carry a status note of at least 40 characters, and the phrases coming soon, work in progress, tbd and may not work are explicitly banned from a beta note. A connector that declares a status the platform does not recognise is downgraded to planned rather than assumed to work.

When you open a single entry, the response carries a plain-language setup hint built from the status. There are five possible sentences and they are worth recognising:

Ready to configure.
Usable with a documented limitation: <the status note>
Usable, with limitations.
This integration is not built yet. <the status note>
This integration is not built yet and cannot be configured.

Why one row can offer a Configure button and no Configure button at once

This is the part that changed most recently, and it is the part people ask about. A row in the catalogue is not one thing you switch on. It is a bundle of capabilities — sign-on, directory reading, notifications, provisioning — and each one is judged separately. So a single entry can show a Configure button beside one capability and, beside the next, a paragraph of prose explaining why there is no button there.

That is not an interface bug. A capability earns a button by passing three tests, in this order.

1. Whatever contributed the capability claims to work. A connector or a template that has marked itself planned is taken at its word, and the check stops there.
2. There is a live route to send the configuration to. Every capability is mapped to a surface, which is the join between a row in the catalogue and an endpoint that is really mounted in the running API. A surface with no connect route cannot accept a form, however complete the code behind it is. A test walks the API's own router and fails the build if this claim drifts.
3. The capability declares fields to fill in. No fields means no form and nothing to save. Single sign-on is the deliberate exception: a SAML or OIDC application is built from a template rather than a credential form, so it is allowed to carry no fields of its own.

When a capability fails, the console prints the reason in the place the button would have been, word for word. It is not a tooltip and it is not a generic unavailable. The one you are most likely to meet is the one about pushing accounts out to another system:

The catalogue list screen shows the same truth as a pair of numbers on each capability filter: how many rows offer that capability, and how many of those you can configure today. A chip reading 9 / 0 is telling you that nine entries declare provisioning and not one of them can be set up. Hovering it says so in words — No integration offers this yet. or {n} of {total} can be configured today.

The three beta rows and exactly what is missing

Three connectors are beta. In each case delivery works and something else does not, and the note says which. These are the sentences the product itself shows you:

The practical consequence for Jira and ServiceNow is the same: Qorionix will open a ticket for you, and a person will close it. We would rather leave that to you than write a guess into your incident reporting.

The nine planned rows, and what to use instead

Planned entries are active_directory_ldap, okta, aws_iam, workday, sap_successfactors, opsgenie, jamf_pro, intune and generic_scim. None of them does anything today. Each carries a note saying what is missing and, where one exists, the route that already works.

• Active Directory over LDAP — needs an LDAPv3 client we have deliberately not taken as a dependency. If you are Entra-joined or hybrid, the Microsoft Entra ID connector is complete and covers the same directory through Graph. See Connect Microsoft 365.
• Okta — Okta can already federate into Qorionix today through the inbound SAML and OIDC surfaces. What is missing is reading the Okta directory outbound, which matters only for a migration.
• AWS IAM — AWS IAM credential rotation already works in the privileged access module. What is missing here is read-only inventory.
• Workday and SAP SuccessFactors — both can already push people into Qorionix using the inbound SCIM 2.0 endpoint at /api/v1/scim/v2, which is the direction Workday itself recommends.
• Jamf Pro and Intune — both are blocked on the adaptive-access policy engine that would consume their device signals. Shipping the connector before the consumer would produce data nothing reads.
• Opsgenie — no committed date. PagerDuty is available and covers the same job.
• Generic SCIM — this row used to describe pushing accounts out to any SCIM 2.0 application. Outbound provisioning is not wired up, and generic_scim offers nothing else, so the whole row is now planned. Pushing accounts into Qorionix still works, through the inbound SCIM 2.0 server at /api/v1/scim/v2. See Inbound SCIM provisioning.

The thirteen categories

Categories are derived from the entries rather than kept in a separate list, so the two cannot drift apart. Each one reports how many of its rows are usable, not only how many exist.

Rows sort usable-first, so the things you can actually turn on are at the top of every list rather than interleaved alphabetically with things you cannot.

What a listing is not

This is the part of the article that matters most, and it is the reason the status field exists at all.

An earlier version of this catalogue declared 69 entries across 18 categories. Its own code comment described them as declarative metadata for a connector stub, and the stub returned nothing from every method. Clicking any of the 69 produced silence. Five hand-written stub connectors sat behind it — LDAP, Azure AD, Okta, AWS IAM and SCIM — each of which validated a configuration and then refused every operation. All of it has been deleted rather than relabelled, on the reasoning that registering a factory which cannot do anything is still a promise the product does not keep.

Two regression tests now hold that line. One fails the build if a connector reporting planned status is registered, and names ldap, azure_ad, aws_iam, okta and scim specifically. The other names fifteen rows from the old catalogue that must never come back: crowdstrike, sentinelone, splunk, sumo_logic, qualys, tenable, snyk, terraform_cloud, oracle_cloud, new_relic, elastic_security, carbon_black, cortex_xdr, wiz and prisma_cloud. If you came here looking for one of those, the honest answer is that we do not integrate with it and are not pretending to.

How to read a row yourself

1. 1

   Filter to what works before you plan anything

   The catalogue endpoint accepts ?usable_only=true, which returns only available and beta rows. It also accepts ?status=, ?category=, ?capability= and ?search=. An unrecognised status value is refused with status must be available, beta or planned rather than silently returning everything.

2. 2

   Open the entry, not just the list

   A single entry adds the setup hint and, for a template-driven row, the fields you would have to fill in and the vendor-side instructions. This is where per-capability status appears, and where you find out that the row you wanted for provisioning is available for sign-on and beta for provisioning.

3. 3

   Check the capability, not the brand name

   The vocabulary is sso_saml, sso_oidc, provisioning, inbound_scim, directory_sync, notify, ticket, response, log_ingest, pam_target and edr_telemetry — eleven kinds, and three of them (inbound_scim, pam_target and edr_telemetry) have no rows at all. The empty ones are deliberately kept in the list so the console can tell you plainly that no integration offers endpoint telemetry, rather than leaving you to infer it from an absence. 'We integrate with Salesforce' is not a useful sentence on its own; 'Salesforce single sign-on is available and Salesforce provisioning is planned' is.

4. 4

   Then configure it

   Follow Configuring a connector, which covers the form, how credentials are stored, and what the test button proves and does not prove.

What to do next

• Configuring a connector — the form, the credential store and the verbatim failure messages.
• Where notifications go — which of these destinations can actually reach you today.
• Connector health and silent failure — how to tell whether an integration you set up two months ago is still running.