What you will be able to do
- Choose between an If/else condition task and a Run if dependency for a branching requirement
- Write If/else operands that reference task values and job parameters
- Predict how ==, !=, >, >=, < and <= evaluate numeric, string and boolean operands
- Wire true and false branches in the Jobs UI and as a condition_task in a bundle
Key concept
Dynamic value reference — A {{...}} placeholder, such as {{tasks.<task_name>.values.<value_name>}} or {{job.parameters.<name>}}, that the job fills in at run time. An If/else condition reads its operands through these references, and a For each task gets its inputs the same way.
1.Two kinds of conditional: on a value, or on task outcomes
A simple job is a list of tasks with dependencies between them. Many production jobs also need to branch: run the transformation only if ingestion added data, or send records down a quarantine path when validation finds bad rows. Lakeflow Jobs gives you two ways to do this, and exam questions often turn on telling them apart.
Run if dependencies look at how upstream tasks *finished*: whether they succeeded, failed, or completed. The If/else condition task looks at a *value*: a boolean comparison between two operands, which can be a number a task computed, a job parameter, or a dynamic value. In the docs' example, a task named process_records counts invalid rows into a value called bad_records, and an If/else task checks whether that count is greater than zero.
| Mechanism | What it evaluates | Example |
|---|---|---|
| If/else condition task | A boolean expression: two operands and an operator | {{tasks.process_records.values.bad_records}} > 0 |
| Run if dependency | The completion status of upstream tasks | All succeeded, At least one failed, All done |
Both tasks in that scenario succeed. What changes is the data, so you need a condition on a value, not on a task's status. The two mechanisms also combine: the If/else docs suggest adding Run if dependencies when branches also need to react to upstream failures.
Checkpoint 1 of 5· Check yourself
A task named process_records sets a task value bad_records. You want a remediation task to run only when bad_records is above zero. What should you add?
process_records succeeds whether or not it finds bad rows, so a status-based Run if can't make this distinction. Comparing the value with an If/else task can.
“with an expression like {{tasks.process_records.values.bad_records}} > 0.”Source: docs.databricks.com
Sources1
2.Where operands come from: job parameters and task values
An If/else condition has three parts: a first operand, a boolean operator, and a second operand. An operand can reference a job parameter ({{job.parameters.<name>}}), a task parameter variable, or a task value ({{tasks.<task_name>.values.<value_name>}}).
Task values are how one task hands a computed result to the rest of the job. An upstream Python notebook writes a key-value pair with dbutils.jobs.taskValues.set(). The value must be expressible as valid JSON, and its JSON form can't exceed 48 KiB. Because set() and get() are Python functions, only Python notebooks can call them. Any task that supports parameters can still *read* a task value through a dynamic value reference, and that is the form an If/else operand uses.
Checkpoint 2 of 5· Fill the gap
This line in an upstream notebook publishes a row count that a later If/else task can compare. Which method completes it?
dbutils.jobs.taskValues. ? (key = "record_count", value = query.count())set() writes a key-value pair that later tasks reference by task name and key. get() reads a value back, and the docs don't recommend using it.
Source: docs.databricks.comDatabricks recommends dynamic value references over calling dbutils.jobs.taskValues.get() in downstream code. get() hard-codes the upstream task name, so renaming that task means editing every consumer. In an If/else operand, writing {{tasks.<task_name>.values.<value_name>}} is the normal pattern. One dependency to watch: an If/else task fails if the upstream task that provides its condition value is disabled.
3.How the operators compare: string versus numeric
The UI lets you choose from six operators: ==, !=, >, >=, <, <=. They don't all compare the same way:
- == and != compare their operands as strings. 12.0 == 12 is false.
- >, >=, < and <= compare numerically. 12.0 >= 12 is true and 10.0 >= 12 is false.
Type rules apply as well. A task value used in an operand must be numeric, string, or boolean. Any other type makes the condition expression fail. Non-numeric values are serialized to strings, so a boolean task value becomes "true" or "false" and is compared as text.
In practice, use == only when both sides will be written identically, as with status strings or booleans. For numbers that may be formatted as 12 in one place and 12.0 in another, use a numeric operator. For example, >= 12 together with <= 12 matches a value equal to 12.
Checkpoint 3 of 5· Match them up
Match each operand or expression to how the If/else task handles it
Tap a term, then the definition that fits it.
Equality operators compare strings and ordering operators compare numbers. Booleans become strings, and any other type makes the expression fail.
“Any other types cause the condition expression to fail.”Source: docs.databricks.com
Checkpoint 4 of 5· Exam question
A Lakeflow Job has an ingestion task `bronze_ingest` that calls `dbutils.jobs.taskValues.set(key="new_rows_count", value=row_count)`. A downstream If/Else condition task `check_new_data` evaluates `{{tasks.bronze_ingest.values.new_rows_count}} > 0`. The team wants a task named `run_silver_transform` to execute only when that boolean evaluates to true. How should `run_silver_transform` be configured?
Correct answer: A — Set `run_silver_transform`'s dependency on `check_new_data` with Run if set to True, so the platform starts the task only once the condition task's boolean result equals true.
- A. This is the correct configuration: an If/Else task exposes a true/false outcome, and a downstream task's Run if dependency setting can be pinned to that outcome so it only starts when the condition resolves to true.
- B. Task values are read with `taskValues.get()` for use as data inside a task's own logic, not as a substitute for the platform's dependency-outcome mechanism, and this approach still runs the task's cluster and startup steps needlessly.
- C. An All succeeded dependency only checks whether the condition task completed without error, not which branch it evaluated to, so `run_silver_transform` would start regardless of the boolean's value.
- D. If/Else is a standalone task type positioned in the DAG, not a construct that can be embedded inside another task's own configuration, so this does not express the intended branching.
Sources2
4.Wiring the true and false branches
In the Jobs UI, you add the condition task from the Tasks tab like any other task. You give it a name, pick If/else condition as the type, and fill in the two Condition boxes on either side of the operator.
Checkpoint 5 of 5· Put it in order
Put the steps for adding an If/else condition task in the Jobs UI in order
- 1.In the Type drop-down menu, select If/else condition
- 2.Click Add task
- 3.Enter the value for evaluating the condition in the second Condition text box, then save
- 4.Enter a name into the Task name field
- 5.Enter the operand to be evaluated in the first Condition text box
- 6.Select a boolean operator from the drop-down menu
The steps follow the documented UI procedure: create the task, set its type, then fill in the operand, operator and comparison value.
“In the Type drop-down menu, select If/else condition.”Source: docs.databricks.com
Next, add the branches. Select the condition task in the graph and click Add task. The new task's Depends on field defaults to <task-name> (true). To make a task run when the condition is false, select <task-name> (false) instead. Each outcome can feed several tasks, and they can run in sequence or in parallel. After the run, the run details page shows the result and how the expression was evaluated.
In a Declarative Automation Bundle, the same task is a condition_task with three required keys: left, op and right. op uses enum names instead of symbols. The valid values are EQUAL_TO, NOT_EQUAL, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN and LESS_THAN_OR_EQUAL. A dependent task picks a branch with outcome in its depends_on. The condition task doesn't need a cluster to run.
resources:
jobs:
my-job:
name: my-job
tasks:
- task_key: condition_task
condition_task:
op: LESS_THAN
left: '{{job.repair_count}}'
right: '5'
- task_key: notebook_task
depends_on:
- task_key: condition_task
outcome: 'true'
notebook_task:
notebook_path: ../src/notebook.ipynbAdd another task whose depends_on lists task_key: condition_task with outcome: 'false'. In the UI, that is the same as choosing condition_task (false) in the Depends on field.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.== compares numbers, so a task value of 12.0 equals 12.Why is that wrong?
== and != compare strings, so 12.0 == 12 is false. Only >, >=, < and <= compare numerically.
2.Disabling the upstream task that sets the condition's value just makes the If/else task skip quietly.Why is that wrong?
The If/else condition task fails when the task that provides its condition value is disabled.
Covered in Where operands come from: job parameters and task values
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/jobs/control-flowOfficial docs
“You can use the If/else task type to specify conditionals based on some value.”
↩︎ Two kinds of conditional: on a value, or on task outcomes“You can use the Run if task type to specify conditionals for later tasks based on the outcome of other tasks.”
↩︎ Two kinds of conditional: on a value, or on task outcomes - 2.
“The operand can reference any of the following: A job parameter variable, for example {{job.parameters.<name>}}.”
↩︎ Where operands come from: job parameters and task values“The >, >=, <, and <= operators perform numeric comparisons of their operands.”
↩︎ How the operators compare: string versus numeric“Only numeric, string, and boolean values are allowed when referencing task values in an operand.”
↩︎ How the operators compare: string versus numeric“Select <task-name> (false) to configure a task that runs on a false condition evaluation.”
↩︎ Wiring the true and false branches“The == and != operators perform string comparison of their operands.”
↩︎ Exam trap 1“An If/else condition task fails if the upstream task that provides its condition value is disabled.”
↩︎ Exam trap 2“with an expression like {{tasks.process_records.values.bad_records}} > 0.”
↩︎ Checkpoint“For example, 12.0 == 12 evaluates to false.”
↩︎ Prediction“Any other types cause the condition expression to fail.”
↩︎ Checkpoint“In the Type drop-down menu, select If/else condition.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/jobs/task-valuesOfficial docs
“Only values that can be expressed as valid JSON are permitted.”
↩︎ Where operands come from: job parameters and task values“they can be used only in notebooks with Python selected as the language.”
↩︎ Where operands come from: job parameters and task values“Databricks recommends referencing task values as task parameters configured using the dynamic value reference pattern {{tasks.<task_name>.values.<value_name>}}.”
↩︎ Key concept - 4.
“Valid values are: EQUAL_TO, NOT_EQUAL, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN, LESS_THAN_OR_EQUAL.”
↩︎ Wiring the true and false branches“The condition task does not require a cluster to execute”
↩︎ Wiring the true and false branches