SailPoint IDN Sources

SailPoint IDN Sources

Product Design · Identity Management · Cloud Transformation · Wizard Flows

Product Design · Identity Management · Cloud Transformation · Wizard Flows

Timeline
2 Years
My Title
Sr. Product Designer
Website
SailPoint

Before

SailPoint's IdentityNow platform helped companies manage digital access across hundreds of systems, from HR tools to cloud storage. The organizations using it were banks, healthcare systems, large enterprises, government agencies — any organization that needed to know who had access to what, and why. Access reviewers touched the system a few times a year. But a smaller group of admins lived in it every day.


That distinction mattered because the platform had been built almost entirely around the reviewers. The admins, who were doing the real heavy lifting, were using a system that hadn't meaningfully evolved in years.


The connector setup experience was the sharpest example of this. There was no wizard, no guided flow, no in-product documentation. When an admin needed to configure a new source connector, the system dropped them into a form with every possible field displayed at once, no indication of which fields applied to their specific use case, and no help if something went wrong. You either already knew what you were doing, or you called support. Checking on sync status meant exporting a CSV. Catching errors early wasn't really possible.


Underneath that, the source area was owned by 7+ engineering teams, each with different priorities and timelines. Every connector behaved slightly differently. There were no shared patterns, no design standards, and no single team that had ever taken real ownership of the whole thing. Most of them had inherited responsibility from managers who'd built pieces of it years earlier and moved on.


The result was slow setup, brittle systems, and a rising support load.

What I did

I led design across a multi-phase modernization effort, starting with the part that hurt users most and building from there.


Phase 1 and 2: Setup Wizard and Configuration

The first priority was the setup flow, which was owned by a single team and had the highest friction and the most support load. I designed the platform's first ever wizard-based onboarding flow, replacing the blank form with a step-by-step guided process. Relevant fields appeared based on connector type and use case. Documentation and help were embedded directly in the UI rather than living in a separate tab no one opened. I built the whole thing on a scalable component sub-library designed to flex across 200+ connectors without requiring a custom design for each one.


Phase 2 extended this foundation into configuration, adding deeper control over data behavior and sync rules, and separating the setup experience from ongoing management for the first time. These were two fundamentally different jobs that had been collapsed into one interface, and separating them clarified the workflows and reduced access configuration risk.


Phase 3: Monitoring

With setup and configuration in place, the next gap was visibility. Admins had no reliable way to track sync status or catch errors before they cascaded. I redesigned the source view pages to surface data health with clear labels, warnings, and summaries directly in the product, shifting admins from reactive CSV exports to proactive in-product monitoring.


Phase 4: Dashboards (in progress at departure)

The final phase looked ahead to a fully insights-driven admin experience, with live dashboards showing aggregation trends, health summaries, and recommended actions across all sources. This phase was still in progress when I left, but the foundation from the earlier phases made it possible.


Throughout all of this, I worked with technical writers to make the in-product copy actually useful, and pushed on the team ownership structure. When it became clear that several of the 7+ teams nominally responsible for pieces of this feature had never actively built for it, the logical move was obvious: consolidate ownership around the teams who'd been doing the work. I said that out loud. Others saw it too. It happened.

Impact

Connector setup went from an undocumented process that required a support call to a guided, self-service experience. Support mentions of connector issues dropped noticeably, confirmed through customer interviews. The component sub-library provided engineering-reusable, design-reviewed patterns for all 200+ connectors, rather than starting from scratch each time. Separating setup from monitoring clarified who was doing what and reduced the risk of misconfiguration. And consolidating ownership from 7+ teams down to 3 meant the feature finally had people consistently paying attention to it.


The project ran for two years and four phases. It was one of the more structurally complex things I worked on at SailPoint, and the kind of project where the design work and the organizational work were inseparable.

content and all work by Grace Duenas

content and all work by Grace Duenas

content and all work by Grace Duenas