OVERVIEW

Scaling up Cloud Data Ingestion (CDI) at Braze.

Cloud Data Ingestion let customers sync data straight from their warehouse, but only through a rigid method. A table must have three strict columns, including a hand-built JSON payload. Marketers, the primary users, usually couldn't build that or had read-only access, so every sync and every change waited on data engineering, often for weeks. Competitors used that rigidity against Braze in deals.

Impact metrics

Shipped from beta to GA, removing the data-engineering dependency that used to gate every CDI sync. Early enterprise demand in beta: roughly a dozen accounts across fintech, streaming, and consumer requested access.

87%

increase of rows synced monthly (~ 284 billion)

Role

Lead designer across data ingestion and CDI team.

Process

Identifying the Strategic Gap

Cloud Data Ingestion (CDI) syncs data directly from a customer's warehouse, Snowflake or BigQuery, into Braze. It was gated behind a rigid requirement. customers had to build and maintain a warehouse table containing three strict columns, an external ID, an updated-at timestamp, and a single JSON payload holding every attribute.

The people who want that data in Braze are marketers and lifecycle teams. They usually cannot build that table, and often have only read-only warehouse access. So setting up CDI, and every later change as small as adding one attribute to the payload, routed through data engineering. That took weeks and created a permanent dependency between the team that owned the data and the team that needed it. This alone added about a month before a customer had CDI running.

It was also a competitive liability. Warehouse-native competitors pitched the opposite story, sync your data as is with no engineering and a marketer-friendly interface, and used CDI's setup friction as a wedge in active deals.

The strategic call was about sequencing. Rather than jump straight to a full no-code interface, the plan was to ship a SQL editor first, as the escape hatch that immediately unblocks technical users, then layer lower-barrier methods on top of it. I owned the design across that sequence as the sole designer on CDI.

Designing for Scale & Ambiguity

I was the lead designer on CDI, and I began the SQL editor while I was still designing the CSV import mapper on the neighboring team. The underlying problem was the same on both surfaces: take a customer's data, in whatever shape it arrives, and map it onto Braze's model. Working both at once is what let the pattern transfer rather than get reinvented, and it shaped how I sequenced this one.

The roadmap was phased and parts of it were still open, what to build first, and how long to keep the SQL editor before a visual layer should take over. Rather than wait for the full plan to settle, I built working prototypes of the SQL flow so product and engineering could react to something concrete months before requirements were finalized, and used those prototypes to pressure-test where SQL should stop and the visual mapper should take over.

The Solution: A validated SQL step inside sync creation

Creating a sync is a five-step flow: configure it, define the data, set notifications, schedule it, then confirm. The SQL editor lives in step two.

Configurations: sync name, data type, and an update-existing-users-only option before any data is defined.

Make SQL a method, not a mandate. The data-definition step presents three equal-weight ways to define the source: a pre-defined Table, a custom SQL query, and a Visual mapper. I designed it as a choice rather than routing everyone through SQL. SQL unblocks the technical user who has read-only access and no curated table today, while the same step is built to hold the lower-barrier methods that follow it.

Data definition: three method cards, with SQL selected alongside Table and Visual mapper, and the SQL editor below.

SQL Editor.

Gate the sync on validation. The expensive CDI failure is a silent one: a sync that looks configured but ingests nothing because the query's shape is wrong. So the editor blocks progress until a Preview and validate step passes, surfacing compilation and schema errors when a required column is missing and previewing the exact rows and types that will land. Nobody can advance a sync that would quietly drop their data. Two supports sit beside the editor for users who know their data but not Braze's requirements: a schema browser, and an assisted SQL generator for a starting query.

Source Explorer and validated preview. Callouts carry the mechanics: the blocking notice that the connection must validate before proceeding, the detected data types on each column, and the note that payload fields sync as attributes while extra columns are ignored.

Put a signal where there was silence. Research had found customers experienced ingestion as a black box, unable to self-serve when something went wrong, and a sync that runs on a schedule fails when nobody is watching. So notification setup is not optional housekeeping buried in settings, it is a required step in the creation flow, with a contact email for sync errors before the sync can exist and optional row-error and success alerts on top.

Notifications: a required contact email for sync errors, with optional row-error and sync-success alerts.

Schedule and Summary close the flow, setting recurrence and gathering every choice onto one editable review screen before the sync is created.

Schedule syncs.

Sync summary.