2.5.3. Parameters and Dynamic Expressions

💡 First Principle: Parameters and expressions make pipelines flexible and reusable—like variables in programming. Instead of creating separate pipelines for each region (copy-paste nightmare), a single parameterized pipeline handles all regions. The parameter says "which region?" and the pipeline adapts.

Scenario: A pipeline processes sales data for different regions. Instead of creating separate pipelines for each region, use a parameter to specify the region at runtime.

Pipeline Parameters

• Definition: Variables defined at pipeline level
• Usage: Referenced in activities using @pipeline().parameters.ParameterName
• Benefit: Single pipeline serves multiple scenarios
• Variables vs. parameters: parameters are read-only inputs fixed when the run starts. Variables (@variables('name')) are mutable and are changed during the run by Set Variable / Append Variable

Dynamic Expressions

• Syntax: @{expression} for string interpolation
• Functions: concat(), utcnow(), formatDateTime(), etc.
• Everything is a function; there are no operators. Use addDays(ts, -1) (negative = past), if(cond, a, b), equals(), greater(), not() and empty(). There's no +, -, == or ?:
• Activity outputs: with a Lookup's First row only off, @activity('Lookup1').output.count is the number of rows returned and .output.value is the rows as an array. Get Metadata with the Exists field returns @activity('GetMeta').output.exists
• Inside ForEach: set Items to an array such as @pipeline().parameters.folders and reference the current element as @item() or @item().tableName
• Example: Dynamic file path based on date

// Dynamic file path expression
@concat('sales/', formatDateTime(utcnow(), 'yyyy/MM/dd'), '/data.parquet')
// Result: sales/2026/01/02/data.parquet

Visual: Parameterized Pipeline

⚠️ Exam Trap: Creating separate pipelines for each dataset variation is a maintenance nightmare. Use parameters and expressions to create flexible, reusable pipelines. Questions asking for the "most efficient" approach are often testing parameterization knowledge.

• Referencing another activity's output: @activity('LookupConfig').output.firstRow.SourcePath reads a Lookup run with First row only (the count and value outputs above apply when it is cleared). If the control table loses or renames the referenced column, that expression fails with property 'SourcePath' doesn't exist; written null-safe (output?.firstRow?.SourcePath) it returns null instead, and the failure surfaces in the activity that uses the value. A path expression that resolves to the wrong folder or date format (yyyy/MM/dd vs yyyy-MM-dd) fails as UserErrorFileNotFound. Either way, check the resolved expression and the Lookup output before blaming the source.
• Empty control table: clear First row only, test @equals(activity('LookupConfig').output.count, 0) in an If Condition, and set a default value in the True branch instead of letting later activities read a row that isn't there.

Key Trade-Offs:

• Parameterization vs. Simplicity: Heavily parameterized pipelines are flexible but harder to understand and debug
• Dynamic vs. Static Paths: Dynamic paths enable automation but can fail silently if expressions produce unexpected results

Reflection Question: Your pipeline needs to process data from folders named by date (e.g., /2026/01/02/). How would you use expressions to construct the folder path dynamically?