In modern data workflows and application development, manually updating information like IDs, dates, or file paths is a recipe for errors and wasted time. This is where dynamic values come in. They are essentially smart placeholders that automatically pull in the correct information when a process runs, making your workflows more automated, flexible, and context aware.
These placeholders, often written inside double curly braces like {{job.run_id}}, get replaced with real, live data at the moment of execution. This simple concept is incredibly powerful, eliminating hardcoded values and allowing different systems and tasks to communicate seamlessly. While many examples here draw from data platforms like Databricks, the core idea is universal. Even a no-code web app builder like WeWeb uses dynamic data binding to help you build production grade web applications, letting you create context driven user experiences without writing a line of code.
What Are Dynamic Values?
At their core, dynamic values are runtime variables you can use in your job and task configurations. Think of them as placeholders that grant you access to a rich set of contextual information about any given process. This includes details about the job itself (like its name or unique ID), the specific task running (like its start time), and even the results or outputs from previous tasks.
By using these references, your automated workflows become smarter. A task can change its behavior based on dynamic inputs, such as checking the result of an earlier task or using the job’s trigger type to decide which path to take. This capability gets rid of a lot of manual configuration, making complex data pipelines easier to build and maintain.
How to Create and Use Dynamic Values
You don’t find dynamic values floating around on their own; you configure them as part of a job or task’s settings.
The Double Curly Brace Syntax
The universal signal for a dynamic value is the double curly brace syntax: {{ }}. This syntax is widely adopted from popular templating engines like Jinja and Liquid, making it familiar to many developers. Anything you place inside these braces is treated as a reference to be resolved when the process runs. The structure is typically {{namespace.identifier}}, where the namespace (like job or tasks) tells the system where to look for the information.
For example, {{job.id}} is a reference to the unique ID of the current job. The system scans for these {{ }} patterns and replaces them with the actual value for that specific execution. It’s a simple substitution, not a code evaluation, so you can’t perform calculations inside the braces. A syntax error, like a missing brace, will usually cause the placeholder to be ignored or treated as a plain string, so precision is key.
Passing Context with Job and Task Parameters
The most common way to use dynamic values is within job and task parameters. You can set up a parameter once with a dynamic reference, and it will carry the correct, up to date information into your task every time it runs.
For instance, you could define a task parameter for an output path like this: /data/reports/{{job.start_time.iso_date}}/. If the job runs on February 21, 2026, the path will automatically resolve to /data/reports/2026-02-21/. Your code then simply reads this parameter and uses the resolved value. This creates a clean separation where the orchestration layer provides the context, and the execution layer uses it, all connected by the power of dynamic values.
Working with Different Data Types and Structures
Dynamic values aren’t just for simple strings and numbers. They can represent complex data structures, which you can access in surprisingly easy ways.
Type Conversion and Formatting
Dynamic references perform textual substitution, meaning they insert values as string literals. You cannot perform calculations or data type conversions directly inside the {{ }} placeholder. For example, {{job.repair_count + 1}} will not work.
However, some references have built in formatting options. Time based values are a great example. You can append an argument to get a specific format, like using {{job.start_time.iso_date}} to get a clean YYYY-MM-DD string or {{job.start_time.year}} to get just the year. These aren’t true type conversions but predefined ways to retrieve a specific representation of a value.
Accessing Records with Dot Notation
When a dynamic value represents structured data, like an object or a row from a database, you can use dot notation to access its individual parts. Think of it as drilling down into the data.
For example, a reference like {{tasks.my_query.output.first_row}} might represent the entire first row of a SQL query’s output. To get the value from a specific column named total_sales within that row, you simply extend the reference: {{tasks.my_query.output.first_row.total_sales}}. This dot notation allows you to treat dynamic values like objects and precisely pick the piece of information you need. If you’re pulling from APIs, WeWeb’s GraphQL integration lets you request just the fields you need, which maps neatly to this dot‑notation approach.
Handling Arrays of Data
Some processes produce a list of results, and dynamic values can handle this by representing an entire array of records. The reference {{tasks.<task_name>.output.rows}} gives you the full result set from an upstream task, typically limited to a reasonable size like 1,000 rows or 48 KB of data.
This is incredibly useful for looping. You can feed this array into a “For Each” task, which will then execute a set of actions for every single row in the array. The workflow engine does the iteration for you, making it simple to process items in a list one by one. A common example is iterating over records from an Airtable base through WeWeb’s Airtable integration.
Converting to Typed Records and Tables
While dynamic values are substituted as text, the system understands their underlying structure. A reference like {{tasks.myTask.output.first_row}} behaves like a single record or a JSON object. Similarly, {{tasks.myTask.output.rows}} acts as a table or an array of records.
When you pass these structured dynamic values to another task, they are often serialized (for example, as a JSON string) and can be easily parsed back into a typed object in your code if needed. However, thanks to dot notation and looping features, you often don’t need to write any parsing code at all. The platform handles the conversion implicitly, bridging the gap between one task’s output and the next task’s input.
Referencing Data from Other Tasks
One of the biggest benefits of dynamic values is their ability to chain tasks together, allowing one task to use the results of another.
Accessing Specific Columns
When a previous task runs a query, you don’t always need the entire result. Dynamic column access lets you pinpoint the exact value you need. For example, {{tasks.sales_summary.output.first_row.year}} would grab only the value from the “year” column in the first row of the sales_summary task’s output. This is perfect for pulling out key metrics or identifiers to use in downstream tasks without needing to process a whole table.
Capturing SQL Outputs
Referencing SQL output is a primary use case for dynamic values. Instead of saving query results to a temporary location and reading them back, you can pass them directly.
- For the entire result set, use
{{tasks.my_query.output.rows}}to feed into a loop. - For just the first row, use
{{tasks.my_query.output.first_row}}. - For a single value, use
{{tasks.my_query.output.first_row.column_name}}.
This creates a seamless, code free integration between your data processing steps. It’s this kind of dynamic data flow that makes building sophisticated, multi-step applications with a tool like WeWeb, connected to your data sources via its integrations, so fast and efficient.
A Closer Look at Supported References
Platforms provide a well defined catalog of supported dynamic values, usually organized by namespace.
The Full Set of Supported Dynamic Values
The available references typically cover every aspect of a job run. Common namespaces include:
job.*: Information about the overall job, like{{job.id}},{{job.name}}, and{{job.trigger.type}}, which could resolve to values likeSCHEDULEDorONE_TIME.task.*: Details about the currently running task, such as{{task.name}}and{{task.run_id}}.tasks.<task_name>.*: References to other tasks by name, allowing you to get their status ({{tasks.MyTask.result_state}}) or custom outputs ({{tasks.MyTask.values.recordCount}}). A custom value can be set in a script using a command likedbutils.jobs.taskValues.set("recordCount", 1024).workspace.*: Information about the environment, like{{workspace.url}}.
Special Options for Dates and Times
Timestamp references are particularly flexible, offering arguments to format the output. In WeWeb, the Date integration helps you capture and display time‑based inputs that pair well with these formats. For any time based value, you can use options such as:
- iso_date: Returns the date as
YYYY-MM-DD. - iso_datetime: Returns the full date and time.
- year, month, day: Returns just the numeric year, month, or day.
- hour, minute, second: Returns the specific time components.
- is_weekday: Returns
trueorfalse, which is useful for conditional logic.
These built in options save you from having to write date parsing logic in your code.
Advanced Applications of Dynamic Values
Once you master the basics, you can use dynamic values to build truly intelligent and adaptive workflows.
Building Conditional Logic
You can use dynamic values to control the flow of your workflow. Many platforms allow you to set conditions for when a task should run. For instance, you could configure a task to only execute if a preceding task was successful by checking if {{tasks.PreviousTask.result_state}} is equal to “success”.
This effectively turns your workflow into a small rule engine, where decisions are made based on live data. You can create branches that run only when an alert is triggered ({{tasks.someSQL.output.alert_state}} == "TRIGGERED") or when a query returns a certain number of records.
A Note on Operators (Min, Max, Avg)
It’s important to remember that you cannot use operators or functions like min(), max(), or avg() inside the double curly braces. Dynamic references are for substitution, not calculation. Any attempt to write {{max(tasks.myTask.output.rows)}} will fail because the system does not evaluate the content as an expression.
If you need to perform a calculation, you should do it in a preceding task (for example, with a SQL query or a short script) and then pass the result using a standard dynamic value.
Practical Examples and Debugging
Let’s look at how this works in practice and how to check your work.
Example of Direct Usage
A simple and common use case is creating uniquely named output files. You could define a file path parameter as: /reports/{{job.start_time.iso_date}}/run_{{job.run_id}}.csv.
If a job with the run ID 550315892394120 starts on February 21, 2026, this string will be resolved at runtime to: /reports/2026-02-21/run_550315892394120.csv. The platform injects the context for you, making every run organized and traceable. To jump‑start a real app, you can start from one of WeWeb’s prebuilt templates and wire up similar dynamic paths visually.
Example of What Not to Do
Let’s say you want to track the attempt number for a task. You might be tempted to create a parameter like {"attempt": "{{task.execution_count + 1}}"}. This will not work. The + 1 is an operator, and the reference will fail to resolve.
The correct way is to pass the value directly with {{task.execution_count}} and then add one inside your task’s code. Remember, keep logic out of the braces.
Reviewing Resolved Values After a Run
So how do you know if your dynamic values worked? After a job run is complete, you can almost always view the resolved parameters in the run details. The user interface will show you the exact values that were substituted for your placeholders. This is an essential debugging step. If you see a placeholder that wasn’t replaced, it usually points to a typo in your reference. For hands‑on walkthroughs of binding and debugging in a visual editor, explore the WeWeb Academy.
By embracing dynamic values, you can create systems that are not only automated but also intelligent and adaptable. These principles are at the heart of modern software development, from large scale data engineering to building custom enterprise products with visual platforms. If you want to see how these concepts translate into building real applications, book a live demo of WeWeb. You can harness the power of dynamic data to build robust web apps faster than ever before.
Frequently Asked Questions about Dynamic Values
What is the main benefit of using dynamic values?
The main benefit is automation and flexibility. They allow you to create reusable workflows that adapt to their context (like the current date or outputs from other tasks) without requiring manual changes or hardcoded information.
Can I do math or use functions inside dynamic value placeholders?
No, you cannot. Dynamic value references are for simple substitution only and do not support operators like + or functions like min() or max(). All calculations should be handled by a task in your workflow, with the result passed via a dynamic value.
How do I check what my dynamic values resolved to?
Most platforms provide a view of the “resolved parameters” in the details page of a completed job run. This lets you see the final, substituted values, which is extremely helpful for debugging.
What happens if I make a syntax error in a dynamic value reference?
A syntax error, such as a typo or a missing curly brace, will typically cause the reference to fail. The placeholder might be treated as a literal string or resolve to an empty value, preventing your task from getting the context it needs.
Are dynamic values only useful in data engineering platforms?
Not at all. The concept of dynamically binding data to an interface or process is fundamental in all software development. No code platforms like WeWeb rely heavily on these principles to allow users to build applications that react to user inputs and data from various sources in real time.
How do I access data from a specific column in a SQL query result?
You can use dot notation to drill into the result. The syntax {{tasks.your_task_name.output.first_row.your_column_name}} will retrieve the value of a specific column from the first row of the query’s output.
Can I use dynamic values to decide whether a task should run?
Yes. This is a powerful feature for creating conditional logic. You can set a task to only run if a condition is met, such as a previous task succeeding ({{tasks.PreviousTask.result_state}} == "success") or a data quality check passing.
Is there a limit to how much data can be passed between tasks?
Yes, there are typically practical limits to ensure performance. For example, a SQL task’s output that can be passed as a dynamic value might be limited to around 1,000 rows or 48 KB. It’s designed for passing context and results, not for moving massive datasets.
