Hi @iurix,

Great question.. 

If you come at it from a scope/locality perspective, it does feel more intuitive for a task-level parameter to win over a job-level parameter when the same key exists. But Databricks currently models this differently in Lakeflow Jobs.

Per the docs, job parameters are defined at the job level and are pushed down to tasks, and when the same key exists, the job parameter takes precedence over the task parameter. See Configure job parameters and Parameterize jobs.

The practical way to think about it is that Databricks treats job parameters more like run-level inputs that flow through the job, rather than as broad defaults that a narrower task scope can override. That same docs set also notes that job parameters can be overridden when you trigger a run, which reinforces that run/job-level precedence model. See Configure job parameters.

So I’d say... your intuition is valid, but the current behaviour is intentional and documented rather than a regression. If you need one task to use a different value, the safer pattern is usually to avoid reusing the same key and instead reference the job parameter explicitly where you want inheritance. The task-parameter docs also call out that the UI warns when you try to define a task parameter with the same key as a job parameter. See Configure task parameters.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.