Loading the documentation…
A data safety guard stops a load before it publishes when its source looks wrong: the source returned no rows, or the run would remove far more of the table than usual. When a guard fails, nothing is published and the table keeps its previous data. Use this page to set the guards, to run once without them when a smaller source is expected, and to read what a guard reported.
| Table | Loads with guards |
|---|---|
| Dimension | Transformations with the Full Reload or Diff Delete pattern |
| Fact | Transformations with the Truncate Insert (Full), Truncate Insert (Periodic) or Truncate Insert (Periodic Loop) pattern |
| Lake | Tables with the Full Reload (Truncate Insert) sync type |
Other patterns and sync types, such as Diff Upsert, Diff Insert (Periodic) or the upsert sync types, have no guards. Every transformation and Lake table that has guards starts with both guards on and a limit of 50%, existing ones included.
What a run "would remove" depends on the table:
| Load | Rows the run would remove | Measured against |
|---|---|---|
| Dimension | The rows this run would mark deleted | The active rows of that source system |
| Fact, Truncate Insert (Periodic) or Truncate Insert (Periodic Loop) | The active rows of that source system inside the run window, minus the rows this run loaded | The active rows of that source system inside the window |
| Fact, Truncate Insert (Full) | The rows of that source system, minus the rows this run loaded | The rows of that source system |
| Lake, Full Reload (Truncate Insert) | The table's rows, minus the rows the extract returned | The table's rows |
A Warehouse run checks the guards once it has its rows and before anything is written to the table. A Lake load checks them right after the extract, before anything is written. A run that fails a guard publishes nothing, and for a Dimension the history step of that run does not run either.
Empty source: On · Delete ratio: On (50%).A copy opened with Open copy starts with the same guards. To change the guards of many transformations at once, use Batch edit: it adds the columns Empty source guard, Delete ratio guard (On or Off) and Delete ratio % when at least one row has a pattern with guards. Rows with other patterns show a dash, with the reason Safety guards apply to full_reload, diff_delete and truncate_insert_* patterns.
With Fail on empty source off, or skipped for a run, a Full Reload whose extract is empty empties the table.
When you expect an empty or a much smaller source, for example after the source system was cleaned up, start one run without the guards:
Only that run skips the guards; the saved settings do not change, and the next run checks them again. The skipped run still checks the guards and records what would have failed, as a Safety Guards Skipped step that reads Skipped for this run: <guard message>. Restarting or retrying a run that was started without the guards keeps them skipped.
A skip is refused in these cases:
Safety guards do not apply to test runs.Transformation "<name>" uses the <pattern> pattern, which has no safety guards to skip.Lake table "<name>" uses <sync type>; only Full Reload (Truncate Insert) tables have a safety guard to skip.A run that failed on a guard carries a shield icon at the end of its row, Run once without guards. It appears in the transformation's Execution > Run Log, in a Dimension or Fact table's Settings > Transformation Runs, and in a Lake table's Settings > Sync Log, to people who can both run the table (Execute/Stop) and edit it (Create/Edit).
Starts a new run of <name> for <date> with the safety guards skipped., and the warning "This run can remove rows from the table."This starts a new, separate run for the failed run's date. A transformation run also reuses the Synchronize Days and Loop Increment Value the failed run used. The confirmation reads Run started without safety guards.
The failed run itself stays Failed. When it was a scheduled workflow run, it keeps holding the schedule back until you restart the run or the workflow has Ignore Error on, as for any failed run (Schedules and when a workflow starts). Restarting it checks the guards again, so it fails the same way unless you changed them.
Click History in the transformation's Data safety guards dialog, or next to the Data safety guards heading of a Lake table. The button appears once the transformation or table is saved. Safety guard history lists the entries newest first, each with the person, the date and time, and a chip:
Empty source: On · Delete ratio: Off.Run #<id> and the note Manual run #<id> for <yyyy-MM-dd HH:mm:ss>: safety guards skipped.A change is recorded wherever it is made: in the popup, in Batch edit or by a builder Mind. Creating a transformation with values other than the defaults records one entry. An empty history reads No safety guard changes yet; if it cannot load, it reads Could not load the safety guard history.
The run ends Failed with a message that starts Safety guard:. It says what the source returned, how many rows the table has, which part of the table was checked, and what to do next. The exact messages are on Warehouse troubleshooting and Lake troubleshooting.
A guard failure is a failure like any other:
Then decide: if the source really is wrong, fix it and restart the run. If the change is expected, use Run once without guards, or change the guards.
| To do this | You need |
|---|---|
| See the guards and their history | View Warehouse Objects or View Lake Objects |
| Change the guards | Create/Edit Warehouse Objects or Create/Edit Lake Objects |
| Skip the guards for one run | Create/Edit on the table, plus Execute/Stop to start the run |
| Use Run once without guards | Execute/Stop and Create/Edit on the table |
See the Permission reference.
The source returned no rows while the table, or the part of it the run replaces, still has rows. Nothing was published, so the table kept its data. Check the source first. If an empty source is expected, use Run once without guards on the failed run, or turn off the empty-source guard.
Start one run without the guards: tick Skip safety guards for this run when you execute the transformation or synchronize the Lake table, or use Run once without guards on the run that failed. If smaller loads are normal from now on, raise Limit (%) instead.
No. The guards are checked before anything is written, so a failed run publishes nothing and the table keeps exactly the data it had.
No. A run fails only when it would remove more than the limit; exactly the limit passes.
Only Full Reload (Truncate Insert) tables have guards, because that is the sync type that replaces the whole table on every run. Other sync types have none, and a run that asks to skip them is refused. For transformations, see Transformation general settings.
No. Only that run skips the guards, and the next run checks them again. The skip is recorded in the guard history with the run number.
The icon appears only on a run whose error came from a guard, and only to people who can both run and edit the table. A run that failed for another reason does not carry it.
Not by itself. The failed run holds the schedule back, as any failed run does, unless the workflow has Ignore Error on. Restart the run once the cause is fixed, or start a separate run without the guards and then deal with the failed run.
Open History next to the guards. Each change shows the person, the time and the new values, and each skipped run shows its run number.
Yes. The Warehouse Builder and Lake Builder can set the guards and start a run without them, with your permissions. Turning a guard off or skipping the guards asks for your approval unless the chat runs in Unrestricted mode. See Warehouse Builder.