Origin
Pranay, one of our founders, keeps hearing the same sentence from teams about six weeks into a new IGA deployment. The tool works. The manual provisioning queue is still running. Nobody can explain why both are true at the same time.
The demo goes well. Two hundred and forty connectors, and the number climbs every quarter.
The integrations page scrolls for a while. The rep types your tools into the search bar and most of them come back with a logo next to them. Implementation is quoted in weeks rather than the six months SailPoint wanted, at a fraction of the price.
You leave thinking this is what IGA should have been all along.
Then implementation starts. The connector for your collaboration tool works on Business Plus and above, and you're on Business.
The GitHub connector wants Enterprise, and you're on Team. The project management tool engineering has run for three years isn't on the list at all. Neither is the finance tool somebody set up in 2021, or the recruiting platform HR brought in last quarter, or the internal wiki that holds more of your real documentation than the official knowledge base does.
The connector count was accurate. The coverage wasn't.
The mechanism explains every one of those cases, and it's worth understanding before the contract rather than after it.
SCIM, the System for Cross-domain Identity Management, is the protocol that lets an identity system talk to an application. When a modern IGA tool says it connects to an app, it almost always means it speaks SCIM to that app. The connector library is a list of applications that support SCIM, on a plan tier that exposes the endpoint.
Provisioning a new hire sends a SCIM call. Closing a leaver sends another. The automation is real and it stops at the applications that answer.
Applications that don't answer stay where they were. The tool won't provision them, won't close them when someone leaves, and won't include them in an access review. They sit in the same manual queue they were in the week before anyone signed anything.
The vendors who built this way made a defensible call. SCIM is a good protocol, properly specified, widely adopted by the applications that adopted it.
If you set out to automate provisioning at scale in 2019, you built on the standard the applications actually supported. The gap is between what "240 connectors" implies and what "240 SCIM-dependent connectors" delivers, and the fine print has never been on the same slide as the number.
The proportions underneath are public and they aren't close.
We keep an open dataset on this, the SCIM Tax Index, covering around 300 SaaS vendors. Of the vendors that built SCIM at all, 89% put it behind an Enterprise plan or a Contact Sales button. Then there is the larger group that never built it: the legacy systems, the internal tools, the software with a login page and nothing behind it.
Between the two, the share of a normal stack a SCIM-dependent connector library can reach gets small fast, however long the integrations page runs.
Which makes the honest version of the sales claim something like this: we automate the applications in your stack that were big enough to implement SCIM, and that you already pay enough to have it switched on. That's a real product and a useful one. It's also a fifth of a typical environment, and the other four fifths don't become smaller because the contract is signed.
Teams find this out around week six after go-live, when the manual queue is still moving and somebody asks why. The first assumption is always a configuration problem. Implementation must have missed something.
There must be connectors nobody switched on. So another month goes into working the list, the list ends, and the applications that couldn't be connected still can't be connected. There's no configuration fix for a SCIM endpoint that doesn't exist.
We publish a connector count as well, so the fair thing is to say what ours means.
Iden's number counts the applications we automate without SCIM. Where an app exposes SCIM on the plan you already hold, we use it, and that needs no connector from us at all.
Where there's an API and no SCIM, we use the API. Where there's neither, we operate the admin console the way your administrator does, through a custom automation framework built for that specific system. Same login, same menus, same account screen, driven by a trigger from the HRIS instead of by somebody remembering.
That last category is the hardest thing we build and the work we spend the most time on per application. Some systems fight it. When one does, we tell you, rather than putting the logo on a slide and sorting it out during implementation.
Asking a vendor how many connectors they have is a fine question. It just doesn't tell you what your governance will look like in March.
The one that does is simpler. What happens to the applications that aren't on your list?
"We add connectors regularly" is a roadmap answer. "You can build custom integrations against our API" is a headcount answer, and the headcount is yours. "Those would stay manual" is the accurate answer, and it's the one that tells you what you're actually buying.
Ask it about us too. We would rather answer it in a demo than have you work it out in week six.
We'd take your real app list, including the ones no vendor has offered to connect, and show you what comes back. No deck. Just the product.