Braze adds a SQL editor for warehouse ingestion and a visual mapper beta

Two routes from warehouse data to customer attributes

Braze’s 20 August 2026 release notes announce general availability of the SQL editor for Cloud Data Ingestion and a separate visual mapper beta. The editor is available across the supported warehouse sources, including Snowflake, Amazon Redshift, Google BigQuery, Databricks and Microsoft Fabric. The mapper beta initially covers user attribute syncs. These are distinct availability states, not one universally available visual workflow.

The practical difference is how an operator prepares the source. The SQL route supports shaping data through a query. The visual mapper connects existing columns to destination fields without those transformations. For a revenue team, the choice depends on where business definitions are maintained and who can review a change before it alters a customer segment.

Sources: Braze original release

Match the interface to the data contract

The mapper documentation requires an identifier and an updated_at mapping for incremental synchronization. It does not support transformations, conditional logic or joins. Braze directs those cases to SQL. A new source column is not automatically imported; removing a mapped column pauses the sync, and a rename is treated as removal plus addition. These behaviours make schema ownership consequential.

The SQL editor uses read-only queries against the underlying warehouse. Read-only at the source does not mean inconsequential at the destination: the resulting attributes can influence segmentation and messaging. Review the selected fields and the meaning of each output as carefully as a direct write. A technically valid query can still join the wrong account or label an uncertain status as settled.

Sources: Braze visual mapper documentation · Braze SQL editor documentation

Resolve person and account identity first

A warehouse may describe an account, subscription and individual in separate tables. A lifecycle platform needs to know which individual should receive which attribute. Before configuring the sync, write down the grain of the output: one row per person, per account, or another explicitly supported identity. Define what happens when several subscriptions belong to one person or a person belongs to several accounts.

Do not use a convenient email address as an unquestioned substitute for that identity contract. Review changes of address, shared inboxes, merged records and deleted accounts. Where a company-level entitlement informs an individual message, make the relationship visible in the transformation and its review record. Otherwise a clean-looking mapping can distribute one account’s state to an unrelated person.

Treat incremental time as a business dependency

An incremental sync needs a reliable signal that relevant data changed. Ask which operation updates the selected timestamp and whether a change in a joined source advances it. If billing status changes but the person record’s timestamp does not, a superficially reasonable incremental rule may miss the new state. Test the actual source model rather than assuming every table shares the same update clock.

Use a small set of deliberate cases: a new record, a changed value, a missing identifier, a duplicate identity, a null value and a late correction. Record the expected destination for each. For a removal or suppression case, verify the configured behaviour explicitly; absence from a query result should not be assumed to remove a previously imported attribute.

Review changes across data and marketing teams

The warehouse owner should approve the source semantics and the lifecycle owner should approve how the imported fields are used. Keep the query or mapping version, reviewer, sample records and acceptance result together. When the source schema changes, the notification must reach someone who can fix the contract, not only someone who notices that a campaign audience stopped moving.

A useful release exercise follows a test person from warehouse input through the sync result and into a non-sending segment preview. Check that exclusions remain intact and that a failed or stale sync cannot silently make a customer eligible for the wrong message. This is a proposed operating test, not a claim that the release supplies a complete campaign approval system.

What the update changes for RevOps

The new interfaces can move part of the preparation work closer to the sync configuration. They do not remove the need for a durable definition of customer state. A team with a reviewed warehouse model may prefer to preserve that model and map its stable output. A team needing a bounded transformation may find the SQL route more appropriate, provided the change receives the same review as upstream data work.

Judge the implementation by explained records and recoverable failures. Can an operator show why a person received an attribute, which source version produced it and what would happen after a rename or late correction? That evidence is more useful than counting how many columns were connected. Start with one meaningful attribute and expand only after its full lifecycle is understood.