Okta
Designing the future of Okta's Integration Platform
Okta Integration Network: replacing a bespoke, one-off review process with a single extensible framework for how ISVs build, submit and publish integrations — one manifest schema, one shared UI kit and one validation engine behind every category.
Impact
- 61%
- Submissions resolved without a human review, first pass
- -48%
- Time from first submission to published, down from 23 days to 12
- 2 of 4
- Integration categories on the framework at launch; the rest followed without a rebuild
Business
Case snapshot
The situation
Every new integration category meant building the submission flow again, by hand.
The Okta Integration Network is the catalog of third-party apps and services that plug into Okta — single sign-on, provisioning, workflow automation — and OIN submission is how an ISV gets an integration listed as supported. Getting into that catalog ran through a handful of engineers reading each submission by hand: checking a manifest against a spec that lived in three different documents, testing the integration in a sandbox, then emailing the ISV back with what to fix.
That worked when submissions were rare and reviewed by someone who had written the spec themselves. It stopped working as the catalog grew and the categories multiplied — SSO looked nothing like SCIM provisioning, which looked nothing like a workflow connector, and every category had picked up its own ad hoc review process, its own inconsistent error messages, and its own tribal knowledge about what actually passed.
The cost showed up on both sides of the review. ISVs were resubmitting the same integration three times on average before something passed, most of it for problems a machine could have caught in seconds. The review team was the bottleneck for every category at once, which meant a growing catalog was making the thing meant to scale it slower, not faster.
What was at stake
A stalled catalog
Every quarter the submission backlog grew faster than review capacity, and a thinner catalog is a weaker story against every other identity platform courting the same partners.
ISV goodwill
A partner with real engineering resources elsewhere would try Okta once, hit an opaque rejection, and quietly deprioritize the integration.
A team stretched flat
Four categories were each maintaining their own submission tooling, so every improvement had to be built four times or not at all.
The problem statement I carried into the work: OIN needed one framework that could take on a new integration category without a new team building its own submission flow from scratch — not a better version of the existing review queue.
Goals
Cut the round trips
Most resubmissions were for mechanically checkable problems. Catch those before a human ever opens the submission.
Make it self-service
An ISV should be able to tell, without asking anyone, whether their manifest is valid and where their submission stands.
Build it once, extend it forever
The framework had to onboard a category Okta hadn’t invented yet without a new design or engineering build.
Keep the judgment calls human
Security and trust review is not a rule engine. Automating the mechanical checks had to free that time, not remove it.
My scope
I owned the framework's model; four category teams owned what they built on it.
- What I owned
- The framework’s information model — what a manifest is, how a submission moves through states, what "valid" means before a human ever looks at it — plus the shared component set every category’s submission flow is built from, and the case for funding it as a platform investment rather than a queue-management fix.
- What I influenced
- Each integration category (SSO, provisioning, workflow, and the newest, event hooks) had its own category-specific fields and validation rules, owned by that category’s design and engineering pair. I came in only where a category’s needs would have forced a change to the shared model.
- Who I worked with
- 3 designers — one on the framework and shared components, one embedded with partner engineering on the manifest schema, one on the developer portal’s documentation and onboarding — plus 14 engineers and one PM.
- Who I reported to
- The Director of Design for Developer Experience, with a standing weekly alongside the partner engineering lead who owned the review pipeline’s backend.
- How I was measured
- Submissions resolved without a human touching them, time from first submission to published, and whether a new integration category could launch on the framework without a design or engineering rebuild.
Stakeholders
Partner engineering
Owned the validation engine and the review pipeline’s backend. The manifest schema was a joint document — neither of us could change it unilaterally once ISVs were building against it.
Developer relations
Owned the public docs and the direct relationship with ISVs — my clearest signal for what was actually confusing developers, ahead of any usability session.
Security & trust review
The team whose judgment the automated checks existed to protect, not replace. I brought them into the model work early so "what can safely be automated" was their call, not mine.
ISV partners
Not in the building, but in every round of validation — real manifests from partner ISVs across all four categories tested the framework before it shipped.
The hard call
I argued for one extensible framework over four faster category fixes.
The fast option was in front of us: each category team fixes its own worst friction points independently. SSO ships better error messages, provisioning ships a status tracker, and everyone ships something in a quarter instead of nothing for two.
I argued against it, because that path was the one that had produced the problem in the first place — four teams solving the same underlying issue four different ways, with four different vocabularies for the same concepts. A faster version of that is still four things to maintain, and the fifth category still starts from zero.
The alternative was slower and riskier: one manifest schema, one validation engine, and one shared UI kit that every category’s submission flow is built from, with category-specific rules layered on top rather than the whole flow rebuilt underneath. That meant no category team shipped anything in the first quarter — the framework had to exist before anyone’s friction actually improved, which is a hard thing to defend in a review with four impatient teams watching each other wait.
Technical constraints
No enforced schema to start from
The "manifest spec" that existed was three overlapping documents, none machine-readable. The framework couldn’t validate anything until partner engineering and I agreed on one schema that was actually a contract, not a description.
Live ISVs mid-submission
Submissions already in flight when a category cut over couldn’t be silently invalidated — the framework had to accept both the old and new manifest shapes for a transition window.
Review capacity, not headcount
We couldn’t add reviewers. Whatever the framework didn’t catch automatically stayed exactly as slow as it already was.
Trade-offs
Generality over a perfect first category
SSO’s flow is less tailored to SSO specifically than it could be if built for SSO alone — the cost of keeping the model honest for provisioning and workflow, which came later.
A schema strict enough to validate, loose enough to extend
A stricter schema catches more automatically; a looser one lets a category we haven’t invented yet fit without a schema change. We erred toward extensible and left some checks a category team wanted as manual for the first release.
A framework that only works for the category you designed it against is a rebuild waiting for the next one, wearing a different name.
How the work got made
An audit, a journey map, and a blueprint before a single shared component got drawn.
We started by mapping what already existed rather than what should exist. The existing-experience audit walked every category’s submission flow, every review-team runbook, and every rejection-email template we could find, and it surfaced the same finding from three directions: nothing about the process was visible to the person waiting on it. An ISV who submitted a manifest had no way to know if it was in a queue, being reviewed, or stuck on a question nobody had asked them yet.
Design principles
State is not optional
Every submission has a visible status, everywhere it appears — console, manifest editor, docs. If an ISV has to ask what’s happening, that’s a defect in the surface, not a support ticket.
Fail at the field, not at the end
Validation runs against the manifest as it’s written, not as a rejection after a full review cycle. An error names the field and the fix, not just the rule that broke.
One schema, no synonyms
A concept has one name across every category’s docs, error copy and UI. The old system had three names for a redirect URI depending on which category’s docs you read.
Engineering collaboration
The schema was reviewed like code
Manifest schema changes went through the same pull-request review as the validation engine, with partner engineering and me as required reviewers on both sides — reviewing a schema change as only an engineering decision was how the old spec drifted into three documents in the first place.
Error copy was written with the rule, not after it
I sat with the engineers writing validation rules so the message a rule produced was drafted alongside the rule itself, not bolted on once a category team complained the existing one was unreadable.
Every category tested against real ISV manifests before launch
We ran actual submissions from partner ISVs through the framework in staging before any category cut over, rather than testing against manifests we’d written ourselves to pass.
The craft
The framework, the components it’s built from, and the portal an ISV actually uses.
The craft here is mostly structural — an information architecture and a component set an ISV moves through, not a single hero screen. What follows is what an ISV actually touches, from the manifest to the published listing.
Reusable components
Manifest editor
Validates against the schema as the ISV types, with inline errors at the field. It replaced a text upload that failed silently until a human read it.
Status timeline
One component, shared across the console and the docs, rendering wherever a submission’s state needs to show — the same component the review team’s internal tools use, so what the ISV sees and what’s actually true can’t drift apart.
Category field sets
The piece that lets a new integration category plug in its own fields and validation rules without touching the shared schema or the editor itself — what made "extensible" a real property rather than a claim.
Every shared component meets WCAG 2.1 AA on its own — keyboard-operable end to end, validation errors announced to assistive tech at the field rather than only summarized at the top of the form, and focus management that survives an inline error appearing without a page reload. An ISV’s own engineering team includes people who rely on this, and a submission tool that fails for them is a partner Okta loses before the first review.
Impact
What changed, and how we knew.
We validated in two passes: structured usability sessions with ISV engineers working through real manifests before launch, then instrumentation on the shipped framework once the first two categories had cut over, so the before/after wasn’t only what the audit had found.
Business
- 61%
- Submissions resolved without a human review, first pass
- -48%
- Time from first submission to published, down from 23 days to 12
- 2 of 4
- Integration categories on the framework at launch; the rest followed without a rebuild
Team and craft
- 38
- Shared components adopted across every category
- 24
- ISVs whose real manifests validated the framework before launch
- AA
- WCAG 2.1 conformance across the shared component set
The number I’d point to first is "2 of 4, and the rest followed without a rebuild." That was the actual bet — not that the first category would be smoother, but that the third and fourth would cost nothing extra to onboard.
What I'd do differently
Two places I moved slower than the work needed.
I under-invested in the schema’s documentation
The schema was reviewed as carefully as code, but I treated explaining it to ISVs as a developer-relations problem instead of a design one. The manifest editor’s inline validation covered for that gap more than it should have had to — a developer reading the docs cold still hit the same confusion the audit had already found once.
I let "extensible" stay abstract for too long
The argument for a general framework is easiest to make with a second category already running on it, and I made the case before we had one — on the strength of the audit and the architecture alone. It was the right call in the end, but I spent more of the review cycle defending an abstraction than I would have if I’d pushed to stand up a rough second category earlier, even an ugly one, just to make the claim concrete.
For the detailed case study, reach out to me (opens Gmail in a new tab).