A modern, spreadsheet UI for Enriching CRM data

Earlier this year, Apollo hosted our largest and most ambitious hackathon to date: ApolloHacks 2025. Many teams participated with innovative ideas and one of these ideas now coming to life is this Spreadsheet UI.

In the data-driven world of B2B sales and marketing, having accurate, comprehensive CRM data is non-negotiable. Yet, the process of enriching that data has remained clunky, unintuitive, and frustrating for users. This blog explores how we identified this critical problem and built a solution that transforms the CRM enrichment experience through a modern spreadsheet interface.

The Problem: CRM Enrichment Wasn't Flexible

Meet Alex, a data administrator at a fast-growing startup. Alex's job is critical: keeping CRM data clean, accurate, and up-to-date to empower go-to-market (GTM) teams. Like many data professionals, Alex had done everything by the book - connected the CRM, mapped all fields, configured integrations – and was eager to see the value of enriched data.

But when Alex arrived at the CRM enrichment page on Apollo to enrich the stale data, instead of performing the enrichment confidently, Alex found the experience challenging and unclear.

The existing UI presented several technical challenges:

• ↗️ Multi-step interactions: Core enrichment actions required multiple clicks and navigation through nested UI layers, increasing cognitive load and time-to-completion
• 💔 Fragmented data presentation: Enrichable fields were distributed across separate views and accordion sections, preventing users from seeing the complete, unified enrichment surface area at once
• 📦 Limited bulk operation support: The architecture lacked primitives for efficient multi-record or multi-field enrichment, forcing users to perform repetitive individual operations
• 🔎 Poor scannability: The nested table structure made it difficult to quickly identify which records had enrichable data and what fields were available for enrichment
• 📐Suboptimal information architecture: Customer feedback had highlighted confusion around workflow sequencing and uncertainty about where to find enrichment capabilities

Our data also confirmed this wasn't an isolated issue. The metrics revealed some more UI bitterness

• Teams were using manual CRM enrichment features at lower rates than we had hoped for
• Retention rates indicated users found the existing enrichment experience demanding more effort than the value it provided

The Solution: Reimagining Enrichment over a Spreadsheet

Our breakthrough came from a simple insight: data professionals already have a mental model for working with structured data – the spreadsheet. Spreadsheets have endured for decades precisely because they present data in a unified, scannable view with powerful manipulation capabilities.

There we set out to build a modern, spreadsheet-style interface purpose-built for CRM enrichment, focusing on three core principles:

• Speed: Minimize clicks and maximize efficiency through streamlined interactions
• Simplicity: Create a clear, unified view of all enrichable data with color-coded cells that immediately communicate status
• Scale: Enable actions from individual cells to entire datasets - a mission-critical capability for enterprise teams that routinely manage thousands of records. Unlike the old accordion-based nested tables that required expanding sections to view data, this spreadsheet UI displays everything at once. With 25 records and 10 enrichable columns visible simultaneously, users can now see up to 250 enrichable data points in a single view—eliminating the need for constant clicking and scrolling through nested structures.

Coming back to our data administrator, Alex, this interface gives him a clear, unified view of all enrichable fields right from the grid, with actions available at multiple levels of granularity:

• Cell-level actions (using the ✔️ and ❌ in each cell) for precise control
  

• Row-level actions (using the ✔️ and ❌ in the name cell) for comprehensive record updates

  

• Column-level actions

  

• Multi-cell selection for powerful bulk operations

The Work: Technical Implementation

1. Backend

We made minimal changes to the backend since our primary goal was to enhance the user experience by reducing clicks and simplifying the cluttered data presentation.

In the backend, we had an api enrichment_statuses/search which provided the enrichment related data. We duplicated this to create enrichment_statuses/spreadsheet_search and made structural adjustments to the new API response format to better support the spreadsheet view.

2. Frontend

This is a frontend-heavy project from the beginning. There were subtle small nuances to be addressed in the UI that made user experience better. These were not evident in the first go but small iterations helped.

On the frontend, we organized our implementation around three key areas:

2.1 Visual Design & Information Architecture

The existing nested table structure created significant rendering complexity and poor scannability. We needed to flatten the information hierarchy while maintaining data relationships and making enrichment opportunities immediately visible.

• Replaced the nested table structure with a new spreadsheet layout on the CRM Data Enrichment page
• Added color coding to cells with available enrichments
• Displayed new values at the bottom of color-coded cells

2.2 Interaction Design & User Actions

Supporting multiple levels of granularity (cell, row, column, and bulk selection) required building a flexible action system that could handle different selection states while maintaining consistent UX patterns and preventing conflicting operations.

• Implemented action buttons (✔️ and ❌) on each color-coded cell
• Enabled bulk enrichment for multiple selected records
• Added support for bulk enrichment of multiple selected “individual” cells within records
• Implemented column-wise enrichment through the column header bulk action menu

2.3 Real-time Feedback & State Management

Managing multiple simultaneous enrichment operations required robust state management to track status, handle race conditions, and provide clear visual feedback without blocking the interface.

• Added status indicators ("Enriching..." / "Dismissing...") on the cell during active operations

3. Performance

B2B interfaces are historically context-rich and data-intensive. Despite this complexity, high performance remains non-negotiable in today's landscape. For personas like Alex who need to rapidly sift through large swaths of data and take decisive action, a sluggish interface isn't just inconvenient - it's a fundamental barrier to productivity.

Our UI became performant with virtualization implemented, allowing only visible rows and columns to render. Fortunately, thanks to our existing Design System’s Table component - virtualization was supported out of the boxout of the box!

A small primer on Virtualization

Virtualization is a rendering technique where only the visible portion of a large dataset is actually rendered in the DOM, rather than rendering all rows and columns at once. As users scroll, rows are dynamically added and removed from the DOM.

Benefits:

• Dramatically reduces initial render time and memory usage
• Enables smooth scrolling even with thousands of records
• Maintains consistent performance regardless of dataset size

Tradeoffs We Made:

While virtualization solved our performance challenges, it introduced some complexity as well. Browser-native features like “Cmd+F” search only work on rendered rows, not the entire dataset. We also had to carefully manage scroll position and selection state during dynamic rendering. However, these tradeoffs were well worth it. Without virtualization, rendering 1,000+ records would have created an unusable experience.

Handling Multi-Cell Selection

When implementing multi-cell selection, a significant technical challenge emerged: tracking and managing selection state across the spreadsheet interface. The core difficulty was efficiently communicating which cells were selected from child components up to parent components, handling bulk actions.

The main issue was maintaining an accurate selection state during dynamic mouse interactions:

• As users clicked and dragged across cells, the application needed to track the changing selection boundary in real-time
• Each cell component had its own isolated state, making it difficult to coordinate selection across the grid
• The parent component needed to know precisely which cells were selected to perform bulk actions

Solution

The solution involved implementing a coordinate-based selection system:

• Each cell was assigned x,y coordinates based on its position in the grid (column and row indices)
• When a user initiated a selection, the application stored the starting coordinates (x1,y1)
• As the user dragged, the application continuously updated the ending coordinates (x2,y2)
• The parent component could then calculate which cells fell within this selection rectangle using:
  • Selected cells = all cells where x ≥ min(x1,x2) AND x ≤ max(x1,x2) AND y ≥ min(y1,y2) AND y ≤ max(y1,y2)
• This coordinate system allowed for efficient calculation of the selection regardless of which direction the user dragged (up/down/left/right)

There were clear benefits from going down this route:

• Performance efficiency: Only needed to track two points (start and end) rather than maintaining a list of all selected cells
• State simplification: Parent components only needed to manage two coordinates rather than complex selection arrays
• Intuitive interaction: Users could naturally select ranges in any direction, matching familiar spreadsheet behavior
• Bulk action support: Enabled powerful operations on precisely the cells the user intended to modify

This coordinate-based selection system became a fundamental building block for the spreadsheet UI's bulk enrichment capabilities, allowing users to efficiently update multiple records simultaneously.

The Roadmap: From Hackathon to GA

While our initial vision focused on CRM data, we quickly realized a more pressing need: keeping Apollo's saved records pristinely up-to-date. The spreadsheet UI concept sparked during our hackathon has evolved into a comprehensive roadmap with ambitious, far-reaching goals.

We started off with the "Find People" (Prospecting) page rather than the CRM page. We call it “Enrichment Mode” (You can find it in the Search Settings), which will showcase the enrichable data for each cell along with the action to update or dismiss them.

The "Find People" (Prospecting) page now supports enrichment of saved records for these fields:

• Contacts: First Name, Last Name, Job Title, Company, LinkedIn URL, Location, Email, Phone
• Accounts: Name, Domain, Location, LinkedIn URL, Phone

Currently, we've rolled out certain components of this feature to the teams under a beta cohort (30% of the paying teams) and are closely monitoring adoption metrics and user feedback. The results are promising! We're working toward a full rollout that includes all the above-mentioned features to all customers, bringing this experience to everyone in our ecosystem.

The roadmap includes plans to extend this same seamless experience to CRM contacts and accounts in the future. This expansion represents our commitment to creating a unified, intuitive enrichment experience across the entire data ecosystem.

One more thing - currently, these field enrichments (other than phone and email) are absolutely FREE TO TRY and do not consume any credits.

✨ Join Us ...

Our frontend team at Apollo truly obsesses over making complex B2B software feel lucid, fast, and delightful to use. From reimagining CRM enrichment with a modern Spreadsheet UI to solving deep technical challenges in performance, scalability, and design, we turn complexity into clarity through thoughtful engineering. If this excites you, come build the future of B2B software with us. We are a globally-distributed, fully-remote team of frontend, backend, and platform engineers who take pride in crafting intuitive, high-impact experiences at scale

Explore our careers page!