A dbt full refresh rebuilds an incremental model instead of applying its usual incremental processing. It can be useful when a model's transformation changes and historical rows need the new logic. The decision is about both correctness and scope: which models need rebuilding, what history is available, and what consumes the result?
This guide covers the native command first, then a review workflow for production rebuilds. A small development model may need no manual approval at all.
Run a full refresh for one model
In a configured dbt project, this command requests a rebuild of the selected model:
dbt run --full-refresh --select fct_orders --target devReplace the model and target with names from your project. This command executes work in the warehouse; it is not a dry run.
Incremental models depend on your filtering logic and incremental strategy. If a logic change must apply to historical rows, assess whether the source still contains the history required to rebuild them. The incremental-model documentation explains rebuilds and the conditions that make incremental processing apply.
A rebuild cannot recover source data that no longer exists. Before changing a production table, identify a recovery path that works with your warehouse and retention policy.
Check the full_refresh configuration
The command-line flag does not have the final say. dbt's resource configuration can override it:
| Configuration | Behavior |
|---|---|
full_refresh: true | Requests a full refresh even without the flag |
full_refresh: false | Prevents a full refresh even with the flag |
Omitted or none | Follows the command-line flag |
See the full_refresh reference for the resource contract. Inspect the effective configuration when a model does not behave as expected.
This matters for an approval wrapper too. A script that checks only whether the arguments contain --full-refresh can miss a configured rebuild. Treat the selected resources, configuration, target, and code version as the proposed operation.
Preview selection before executing
Use dbt ls to inspect the model selection:
dbt ls --select fct_orders --resource-type model --output name --target devFor a rebuild that also includes descendants, inspect the expanded selection first:
dbt ls --select 'fct_orders+' --resource-type model --output name --target devThe + selector can broaden the work. Check every returned model before using that selection in an execution command. The list command previews selected resources; it does not provide a warehouse cost estimate or prove that the resulting SQL will succeed.
Run selection with the same project revision, variables, and target intended for execution. Reviewing one configuration and running another defeats the purpose of the preview.
Decide whether the rebuild needs approval
Use your operating policy to distinguish routine development work from a production change that needs review. Size alone is not enough: a small table feeding a customer export can have a larger impact than a large disposable development table.
Prepare these details before asking someone to approve:
Reason for rebuilding:
Project revision and effective configuration:
Target environment:
Exact model selection and expanded model list:
Historical source coverage:
Affected reports, exports, and downstream models:
Estimated duration and cost, with the estimate's basis:
Validation checks after the rebuild:
Recovery plan and owner:
Execution window and approval deadline:If you cannot estimate cost reliably, say what is unknown and propose a smaller trial. Do not fill the request with an invented dollar figure.
Connect the review to execution
A production runner should retain the reviewed operation while it waits. An external approval service can collect the answer, but the runner still owns the command and its warehouse credentials.
For ActionBox, the integration should:
- Save the proposed operation and a stable request identity.
- Create the review request and retain its Action ID and decision binding.
- Wait for a verified human approval for that same proposal.
- Stop the protected command on rejection, expiration, or an unverifiable answer.
- Recheck the operation before execution and record the actual result afterward.
Use the ActionBox quickstart for request creation and the webhook approval integration for verified resume behavior. ActionBox is hosted software; the dbt runner remains your integration.
Do not assemble a shell command from a reviewer's free-text reply. Keep execution limited to the structured operation your application prepared. A changed model selection or target should require another review.
Handle failure after approval
Approval gives permission to attempt the rebuild. It does not establish that all models completed or that consumers can use the output.
| Failure | Next step |
|---|---|
| Reviewer does not answer in time | Stop the proposed run and reassess the execution window |
| Worker loses its connection during execution | Reconcile the warehouse and job state before retrying |
| A selected model fails | Inspect completed and failed work before choosing the recovery scope |
| Post-run checks fail | Hold downstream publication and investigate the data |
| Outcome reporting fails | Recover the report without rerunning the rebuild just to produce a status |
Test the approval and rejection paths with a harmless command before connecting the production target. Then rehearse a model failure in development and confirm that the runner preserves enough information to investigate it.
Full refresh, source freshness, or backfill?
Use dbt source freshness when the question is whether upstream data arrived on time. Use this full-refresh workflow when selected dbt models need rebuilding. Use Airflow backfill when you need historical scheduled runs. A recovery may involve more than one, but each operation needs its own scope.
Create a free Source · Human approval API · Integration docs