Changing how a dbt run behaves with command flags

dbt behavior flags let you control how dbt parses, compiles, and executes projects without changing SQL logic, which is critical when debugging errors that appear only after a dbt version upgrade. Flags are set in the flags section of dbt_project.yml (or via CLI/env vars) and often govern legacy vs. new behavior for things like node coloring, quoting, or materialization logic. Understanding flags helps you distinguish 'real' modeling bugs from version-driven behavior changes.

1 · Learn the must-know

• 1Behavior flags are typically defined under a flags: key in dbt_project.yml and can also be overridden via CLI flags or environment variables for a single run.
• 2When dbt Labs changes default behavior in a new release, they often ship it behind a flag defaulting to the legacy value first, then flip the default in a later minor/major version—so silent breakage after an upgrade is a common exam scenario.
• 3Running dbt --help or checking release notes/CHANGELOG is the standard way to discover which flags exist and their current default in your installed version.
• 4Some flags affect parsing/compilation (e.g., strict validation of properties or configs), so an error that only appears after upgrading dbt Core is a strong clue to check for a related behavior flag rather than assuming the SQL/model is broken.
• 5Setting a flag incorrectly (wrong scope, wrong project file, or typoed key) will usually cause dbt to silently ignore it and fall back to the default, which is a common debugging trap.
• 6Flags are project-wide by default but some can be scoped per-resource or overridden at the command line for testing before committing to a project-wide change.

2 · Check your understanding