Redesigning the connector setup flow to improve enterprise connectivity and search quality
Dec 2025 - August 2026
I led the design of Glean's new connector setup experience, the end-to-end flow admins use to connect their organization's apps to Glean. Our goal was to unify a disjointed setup experience and resolve friction in a multi-week setup process that was costing pilots and slowing deal conversions.
I defined the flows for both admin setup and end-user authentication flows, covering MCP, indexing, and tool activation across 100+ connectors such as Slack, Microsoft O365, and the Google Suite — each with a different authentication model and its own technical constraints.
I worked with product and engineering to define a setup framework that could scale across hundreds of connectors, replacing a fragmented process with one that increased time to value and led to higher product adoption across customers.
The problem: value came too late
Connecting company apps to Glean is the first step in every customer's journey. Without connected content, there is no enterprise search, Assistant, or agents. But the setup experience didn't reflect how foundational it was.
One pilot customer described onboarding as “30 days of setup and implementation, and actually 30 days of piloting.” Another lost track of their setup entirely partway through. Internally, we called this period the valley of despair: the weeks admins spent waiting for a full crawl to finish, with little progress to show and nothing meaningful to put in front of employees. The consequences were significant. Roughly 60% of pilots weren't converting to paid customers, and about 40% of support escalations could be traced to crawling and setup confusion.
A second problem sat underneath the first: connectors and the tools built on top of them were split into two separate parts of the product. Admins would configure a connector and never realize there was a separate tab for turning on its tools. Only about 40% of customers had actions enabled at all — for Google alone, ~55% of admins never set up its action pack. Since Glean's agentic capabilities depend on actions being connected, this capped how much value customers actually got from the product.
A fragmented experience led to user friction
A second problem sat underneath the first. Connectors and Actions were split across two parts of the product. Admins could connect an app for search without realizing they also needed to visit a separate tab to enable the actions Glean could take in that app.
Only about 40% of customers had actions enabled for their connectors. For Google—one of Glean's most important connectors—roughly 55% of admins never set up its action pack. Because Glean's agentic capabilities depend on these actions, this fragmented setup quietly limited how much value customers could get from the product.
Establishing a clearer product model
Before redesigning the flow, I pushed to clarify the language around it. Admins think in terms of the apps their organization uses—Google Drive, Slack, Salesforce—not abstract “data sources.” We renamed data sources to connectors to better represent the two-way relationship: a connector brings knowledge into Glean and allows Glean to take action in the original app.
We also renamed actions to tools, aligning setup language with the terminology customers already encountered in Assistant and Agents.
This wasn't just a copy change. It created a simpler mental model: one connector, with search, knowledge, and tools configured together.
Once tools became part of connector setup, the standalone Actions tab no longer needed to exist. We began planning to retire it as connectors moved onto the unified experience.
That transition introduced an important constraint. The new flow would become the default for new customers, while existing customers needed their previously configured connectors to keep working without disruption. I had to design both the ideal future state and a practical path toward it.
Designing a framework, not a one-off flow
This wasn't a redesign of a single screen. Glean supports more than 100 connectors, each with different authentication models, required inputs, and technical constraints. Some support live connections, some rely on federated access, and others require a full index.
Trying to solve every edge case at once would have forced us to design in the abstract. Instead, we scoped the first phase to roughly ten of the most commonly used connectors. We used Notion as the pilot and Box as an early exploration target.
Whatever we built needed to work as a framework: flexible enough to add or skip connector-specific steps, but consistent enough that setting up Slack once would teach an admin how to set up Salesforce later.
I aligned the team around three principles:
Deliver value as early as possible. Admins shouldn't have to wait for a full crawl before they can see Glean working.
Default to the simplest successful path. Recommended settings should work for most customers, with advanced controls available when needed.
Keep the pattern consistent across connectors. Technical differences should not force admins to relearn the setup experience every time.
Filler text on advanced…
Exploring simple and advanced setup
I began by sketching two ends of the setup spectrum using Box. The simple path used recommended defaults, validated requirements up front, and started the crawl automatically. The advanced path gave experienced admins more control over configuration.
In the first version, advanced settings sat behind a toggle and a confirmation modal. But placing a modal on top of another modal added friction without helping admins make a better decision. I flattened the experience instead, keeping the default path simple while placing advanced controls one layer down with clear guidance and an easy way to restore recommended settings.
This established a principle that carried through the rest of the work: make the common path effortless without making the uncommon path impossible.
The pivotal decision: one flow or two?
Glean's setup can involve two types of connection. A live connection can provide immediate search and tools, while full indexing builds Glean's deeper, permission-aware knowledge graph over time.
The central question was whether admins should choose between them at the beginning or move through both as one guided sequence.
Our first concept used a two-card landing page. Admins could choose Live connection, described as “Immediate answers,” or Full knowledge sync, described as “Deeper search and results.”
The hierarchy sent the wrong message. By placing the live connection first and emphasizing immediacy, the design made it feel like the primary product while positioning indexing as an optional upgrade. In reality, indexing is what gives Glean its differentiated, context-rich answers. A live connection was the fast start—not the final destination.
The model also broke down as soon as we applied it across connectors. Slack requires a live-connection step, while SharePoint and OneDrive follow a different model. A pattern built around choosing between two cards required exceptions almost immediately.
Landing on one guided flow
We replaced the upfront choice with a single, sequenced setup flow. Every connector follows the same overall pattern, while individual steps adapt to its technical requirements. A required live-connection step can be included for Slack, omitted for SharePoint, or made skippable when it offers immediate value but isn't necessary to complete setup.
The experience gives admins something useful sooner without weakening the path toward full indexing. More importantly, it establishes a pattern that becomes familiar over time. An admin setting up their fifth or tenth connector should understand what comes next without having to relearn the system.
Brainstorming together
Filler text…
Unifying authentication for end users
Admin setup was only half the experience. After an admin enabled a connector's tools, employees still needed to authenticate their own accounts and decide what Glean could do on their behalf—Always allow, Ask for permission, or Blocked.
Previously, a connector like Notion could ask someone to authorize twice: once for the connector and once for its actions, because the two systems did not share a token. To users, these looked like duplicate requests from the same app.
I designed a consolidated Connectors settings page where employees could see every app available to them, connect their account, and manage tool permissions inline. It applied the same principle on the employee side as the admin flow: one place to understand and manage a connector, not two.
Making connector status understandable
Admins also needed a clear way to understand the state of everything they had connected. The Connectors landing page went through three distinct versions as we learned what information was both reliable and actionable.
1. Showing literal progress
The first version displayed a progress bar for each connector: “X items indexed out of Y.” But we couldn't reliably calculate the total number of items, and conversations with the support team revealed a larger issue. Once the product showed an exact number, admins expected a level of precision the crawl data couldn't support—and often didn't trust it anyway.
2. Grouping connectors by state
The second version replaced raw counts with clearer states such as Active, Attention required, Syncing, and Setup incomplete. It was more honest about what the system knew, but the table still emphasized metrics, such as crawl rate, that admins rarely acted on.
3. Designing around the next action
The final direction focuses on what an admin needs to understand or fix: indexing status, tool status, and employee access. An onboarding checklist highlights important categories that haven't been connected yet. For active crawls, we show the percentage of priority content indexed rather than an unverifiable total item count.
The support team shared that most admins don't read setup instructions closely. That insight changed the role of the page: it couldn't simply report status; it needed to make the next action obvious.
The complete experience
Together, these changes turn setup from a collection of disconnected configuration tasks into one guided journey:
Start with the apps most important to the organization.
Connect each app through a familiar, adaptable setup flow.
Get immediate value through a live connection when available.
Continue toward full indexing for deeper, permission-aware results.
Enable tools in the same flow instead of discovering them elsewhere.
Return to one landing page to understand progress and resolve issues.
The result is a system designed to shorten time to value while still guiding customers toward the richer foundation that powers search, Assistant, and agents.
Where the work stands
The unified setup experience is currently in a limited pilot with a small group of customers. We are evaluating three core hypotheses:
Can customers reach useful results faster?
Does combining connector and tool setup increase tool adoption?
Does clearer status and guidance reduce setup-related support escalations?
If the pilot validates these bets, the plan is to make the unified flow generally available to new customers and migrate existing customers incrementally.
