Most data teams can tell you exactly which records are failing. Fixing them is another story.
What most teams don't have is a governed way to fix their failed records at scale. When a data quality check fails, correcting the records can mean exporting spreadsheets, chasing record owners and waiting on engineering.
Now, Soda Cleanse brings that work into one review workflow: failed records reach the Inbox, where stewards and record owners review proposed fixes or enter corrections themselves.
The same data contract that validates your data now tells Cleanse what correct looks like, and every fix traces back to the check that caught it.
Soda Cleanse is now available in Private Preview. This post covers what it can fix, how review and approval work, and what your team needs to get started.
Key Takeaways |
|---|
|
You govern the fixes. Cleanse does the cleanup. Request access →
Record Owners Shouldn't Need an Engineering Ticket
The teams closest to a record should be able to fix it themselves. Today the choice is an engineering ticket or a spreadsheet: wait in another team's queue, or fix it by hand, one cell at a time.
That's not a workflow. It's a tax on the teams closest to the data: Sales Operations, Finance Operations, HR Operations, and the stewards who answer to them.
Sales Ops correcting a territory, Finance Ops reconciling a vendor, HR Ops deduplicating an employee each should be able to review the records assigned to them, decide on them, and leave that decision on the record.
Cleanse is built so they do: assignment rules route each issue to the team that owns the record, and every decision lands in the activity log.
Stewards stop fixing records and start governing the process: approving what Cleanse proposes, skipping what doesn't hold up, and leaving every decision on the record.
How Soda Cleanse Works
Soda Cleanse is contract-driven and steward-approved. Each failed check on a row becomes an issue. The remediation strategy on that check generates a proposal or leaves the correction to a person, and nothing is written until you approve it.
The Inbox is Soda Cleanse's center of gravity. It’s where data stewards decide who reviews which issues and how each check gets fixed, and where the record owners they support review the issues assigned to them. It’s a workflow application with an audit trail.
See how a steward's day runs in Soda.
↗The Inbox in Focus view: one record at a time, with each failed value's current value, suggested fix, confidence score and AI explanation. Apply one fix, apply them all, or skip the record.
Three things happen on a loop:
1. Ingest
Once the ingestion webhook is set up, failed rows land in the Inbox after every scan, each with its check context attached. Each failed row gets one issue for each check it fails.
When a row fails again, its issue reopens instead of opening a duplicate. You don't build an integration, export a file or maintain a pipeline to get them there.
2. Propose
The data contract defines what correct looks like, and how to fix what isn't.
Column-level missing, invalid and failed-rows checks: constant, SQL, LLM or manual.
Duplicate and dataset-level failed-rows checks: LLM or manual.
Constant and SQL never call a model. Low-confidence LLM or SQL proposals fall back to a person.
An admin starts a remediation run on the dataset. Generated proposals carry confidence and an explanation; with a manual strategy, the reviewer supplies the correction.
3. Apply
Approved fixes wait in the Fix Queue until someone writes them to the dataset's fix destination: a separate fixes table, in the same data source or another one — or even Salesforce, where Cleanse updates the records directly.
Cleanse never changes the source table, so your team decides how and when corrected values reach it. Nothing changes in your data without a steward signing off.
Cleanse keeps an audit trail alongside its issues and fixes, and its activity log is there to review when an auditor asks what happened to a record.
Soda Cleanse closes the loop on data quality. Contracts define correct. Agents fix what isn't. Stewards govern the outcome.
💡 For a deeper look at the evolution from manual scripts to agentic cleansing, read our Guide to Modern Data Cleansing.
What Soda Cleanse Can Fix
Cleanse supports remediation for missing values, invalid values (including reference-data mismatches), duplicates and custom SQL failed-rows checks. The available strategies depend on the check type, and manual review is an option for each supported type.
Missing values
Missing values slip through schemas because NULL is often technically valid. A missing-value check brings those records into review. The configured strategy supplies a proposed value, or a person enters the correction manually. The steward approves, edits, or skips.
Deduplication
When a duplicate check fails, Cleanse groups the matching records into a single issue on the Inbox's Deduplicate tab. With an LLM strategy, the model proposes which record to keep, following your prompt. The reviewer approves that choice or picks another record; a manual strategy leaves the choice to the reviewer. With a Salesforce destination, Cleanse then deletes the records that aren't kept.
Invalid values and reference-data mismatches
When a value fails an invalid check, whether a bad format, a value outside the allowed list or one missing from a trusted reference table, the right answer often already exists. A SQL strategy looks it up directly, with no model involved. An LLM strategy can also be pointed at your reference tables, so its suggestion is grounded in your own values instead of a guess.
Ready to see how Cleanse handles these failures on the records your team owns? Request Private Preview access →
What contract-driven cleansing gets you
Keeping remediation strategies alongside checks in your data contract gives your team three practical benefits:
Maintain detection and remediation together. The check defines the problem; its remediation strategy defines how to propose a fix or route the correction to a person.
Trace corrections back to the rule. Reviewers can connect each correction to the failed check that brought the record into review.
Control when approved fixes are written. Approval moves a correction into the Fix Queue. A separate Write All action writes approved fixes to a dedicated fixes table or directly to Salesforce. For warehouse data, your team decides how to apply those fixes to the source.
Soda Cloud finds it. Cleanse fixes it. One contract, one workflow, one audit trail.
How To Get Started
💡 Soda Cleanse needs Soda v4 with the Diagnostics Warehouse, a licensed extension our team enables for you, and failed-row collection turned on for the checks you want fixed. If you're on an earlier version of Soda, we'll plan the upgrade with you.
Choose one customer or vendor table your team repeatedly corrects by hand. If its failed rows already reach the Diagnostics Warehouse, we'll work with you to pilot Cleanse on one failure type before expanding.
Not yet on Soda? Talk to our team and we'll plan a rollout that gets your stewards into the Inbox on one dataset first.
We help with the setup. Your team still owns four decisions:
Which checks collect failed rows, so their failures reach the Inbox.
Which remediation strategy each check uses, set in the data contract.
Who approves fixes.
Where approved fixes land: a fixes-table destination for each dataset, or Salesforce directly.
Only Cleanse admins can edit remediation strategies, and saving one publishes a new version of your contract to Soda Cloud. If your contracts live in Git, add the remediation blocks to your contract files too, or the next publish from Git removes them.
What's Next
Private Preview is the beginning. We're working closely with early stewards and record owners to make sure proposed fixes are accurate enough to approve quickly, and to understand how different governance setups affect the review workflow.
Request Private Preview access and we'll get your first dataset into the Inbox.
Already a Soda user? Join the conversation in Soda Community Slack — your feedback on which failure types matter most shapes what we build next.
Frequently asked questions
Who is Soda Cleanse for?
Data stewards, record owners, and the business teams accountable for data in systems of record. Cleanse is designed so these teams can fix the records they own without waiting in an engineering queue for each fix.
Where does my data go when Cleanse proposes a fix?
Failed rows are stored in your own warehouse, in the Diagnostics Warehouse, under your existing access controls. Cleanse runs in your own Kubernetes cluster and keeps its issues, fixes and audit trail in a PostgreSQL database you control. Data goes to a model only for checks with an LLM strategy, including duplicate checks configured to use one: the whole failed row, plus any reference data linked to that strategy, is sent to the LLM provider you configure, under your own API key. If the strategy is also given a tool, such as web search or Google address validation, the model can call that service while it works. Constant and SQL fixes use no model at all.
Does Soda work with my existing stack?
Soda Cloud does: it scans the warehouses your data lives in, including Snowflake, Databricks, BigQuery and Redshift, pushes quality results to catalogs like Collibra, Atlan and Alation, and sends alerts and incident updates to Slack, Teams or Jira. Soda Cleanse reads failed rows from a Diagnostics Warehouse on PostgreSQL, Snowflake, BigQuery or Databricks, and writes approved fixes to a fixes table in PostgreSQL, Snowflake, Databricks or Athena, or straight into Salesforce records.
What does my team need to deploy Soda Cleanse?
Cleanse runs in your own Kubernetes cluster, so your platform team deploys it first, with the Helm chart Soda provides when you join the preview. It needs a PostgreSQL database for its issues, fixes and audit trail, an API key for the LLM provider you choose, and a public HTTPS URL so Soda Cloud can start ingestion after each scan. From there, for teams already on Soda v4 with data contracts in place, the setup is short: connect Cleanse to Soda Cloud, which gives it your Diagnostics Warehouse and data sources, link a dataset and set its fix destination. Your contracts already exist; for each check you want fixed, turn on failed-row collection and add a remediation strategy to the check. For teams starting from scratch, we'll scope the first contract and pilot dataset with you.
How is Soda Cleanse different from rule-based remediation platforms?
Soda Cleanse uses the checks your teams already maintain in Soda data contracts to connect detection with remediation. It reads their failed rows from the Diagnostics Warehouse, the remediation strategy on that same check generates a proposal or leaves the correction to a person, and every fix traces back to the contract check that caught it.
