@clickzetta/cz-cli-darwin-x64 0.3.95 → 0.3.96

package/bin/skills/lakehouse-doc-en/references/task_group.md

@@ -0,0 +1,158 @@
+# Task Group
+
+## Concept
+
+A task group is a virtual business management group within the development module used to manage a list of tasks. You can use task groups to organize and orchestrate a series of tasks — including adding or creating task nodes, defining dependencies between nodes, configuring task group parameters, and performing unified batch submission.
+
+This article covers how to create, edit, and submit task groups, as well as how to copy them.
+
+## Usage Restrictions
+
+1. Only periodic tasks can be added or created within a task group. Real-time tasks are not supported at this time.
+
+2. Task group parameters only take effect after the task group has been submitted and published. Until then, any task node that references a task group parameter will not have access to the configured variable value during execution.
+
+   For example, if a task group parameter is set to `aaa=2023` and a task references it, but the task group has not been submitted, the instance parameter will appear empty during periodic execution.
+
+3. A task node can only belong to one task group.
+
+4. Downstream link copying: Only nodes within the current workspace can be copied. If the downstream link includes task nodes from other workspaces, those nodes will not be included in the copy.
+
+## Use Cases
+
+### Scenario 1: Batch Task Copy and Dependency Management
+
+When you need to batch-copy a group of tasks that have dependencies and recreate those dependencies in the new tasks, you can use the task group copy feature.
+
+![](.topwrite/assets/91c6efc6cd/3c6fcb545a6b507a072943955259ae593b4f1892.jpeg =700)
+
+Add the tasks you want to copy (along with their dependencies) to Task Group 1. After copying Task Group 1, the resulting Task Group 2 will contain:
+
+1. Copies of all tasks in Task Group 1.
+2. Nodes that had dependencies within Task Group 1 (such as nodes B, C, D, E, F) will maintain those same dependencies in Task Group 2.
+3. Nodes outside the task group that had dependencies with nodes inside it (such as nodes A and G) will maintain their original dependencies.
+
+### Scenario 2: Task Pipeline Refactoring and Batch Variable Updates
+
+When you need to refactor a branch in the current task pipeline and batch-update custom variables across tasks, you can combine the downstream link copy feature with task groups.
+
+![](.topwrite/assets/91c6efc6cd/f8dfd42b7ace23593c3f7d3d79bff8eb46d2a1f9.jpeg =751)
+
+On any node (whether it belongs to a task group or is standalone), clicking "Copy Downstream Link" will batch-copy that node and all its downstream nodes.
+
+## Creating a Task Group
+
+Before creating a task group, plan and design a business process that fits your needs. Here are the detailed steps:
+
+1. Create a task group.
+
+**Method 1**: Click "Development" in the left navigation bar → hover over the "+" icon → click "Task Group."
+
+**Method 2**: Click "Workspace" in the left navigation bar → hover over the New button → click "Task Group."
+
+2. In the New Task Group dialog, enter the task group name.
+
+3. Click OK.
+
+![](.topwrite/assets/image_1722251763584.png =434)
+
+After creation:
+
+* You can manage task nodes within the task group, including creating new tasks or adding existing tasks to the group.
+* Once all tasks in the task group are developed, you can submit the entire task group to the production environment directly.
+
+## Editing a Task Group
+
+You can design and manage task nodes and dependencies within a task group in either list mode or DAG mode.
+
+![](.topwrite/assets/image_1722251928404.png)
+
+1. **Create/Add nodes**: Both modes support creating new task nodes or adding existing tasks to the task group.
+
+* **DAG mode**
+
+  * Add existing tasks: Click "Add Existing Tasks" on the right, then drag tasks from the list onto the DAG canvas.
+  * Add new tasks: Under "Add New Task," drag any task node onto the canvas. A creation dialog will appear. Enter the task name and folder, and the new node will be added to the task group.
+
+  In DAG mode, click "Added Tasks" at the bottom right to highlight the corresponding node in the diagram.
+
+* **List mode**
+
+  * Click the "Add" button in the top-right corner of list mode to choose between adding an existing task or creating a new one.
+
+After successfully creating or adding a node, enter the node's editing interface to write the code.
+
+2. **Create dependencies between tasks**:
+
+* In DAG mode: Set scheduling dependencies by dragging dependency lines between nodes. You can also manually edit dependencies through the node's scheduling configuration interface.
+* In list mode: Dependencies for newly created nodes can be set automatically based on code lineage or configured manually.
+
+3. **Task group parameters**: These are global parameters for the task group. After the task group is submitted to the production environment, these parameters automatically apply to any task nodes that reference them. Task nodes that were submitted before the task group parameters took effect need to be resubmitted to use the parameters.
+
+* Click the "Parameters" tab in the task group operation area to open the parameter configuration interface.
+* Click the New button and enter the parameter name and value in the dialog. For details on built-in parameter values, see [Task Parameters](task_param.md). For the full syntax, see [Task Parameter Syntax Reference](task_param_reference.md).
+
+  ![](.topwrite/assets/image_1722252018555.png =497)
+
+After creating task group parameters, use them as follows:
+
+* In the SQL code of a task node, enter `${task_group_parameter_name}`, or enter the parameter name in the scheduling configuration's parameter settings.
+
+  ![](.topwrite/assets/image_1722252076469.png =496)
+
+* In the "Value Source" dropdown, select the task group parameter.
+
+  ![](.topwrite/assets/image_1722252102342.png =472)
+
+After creating and referencing a task group parameter:
+
+* Task nodes can only use the task group parameter values after the task group has been submitted to the production environment.
+* If a task group parameter is updated, the task node must be resubmitted for the change to take effect.
+
+### Batch Edit Scheduling Time
+
+You can use the batch edit scheduling time feature to update the scheduling time for all (or selected) tasks in the task group at once, reducing the effort of configuring each task individually. Steps:
+
+1. Click "Batch Edit Scheduling Time."
+
+* In DAG editing mode: Hover over the batch button and select "Edit Scheduling Time."
+  ![](.topwrite/assets/image_1736303777548.png =498)
+* In list mode: Select the target tasks you want to update, then click "Edit Scheduling Time."
+
+2. Batch edit the scheduling time.
+   Select the scheduling time for the batch update. The operation is the same as the scheduling configuration in task scheduling. For details, see [Task Development and Scheduling](task-develop.md).
+   ![](.topwrite/assets/image_1736303843406.png =499)
+
+3. Confirm and submit the batch operation.
+
+## Submitting a Task Group
+
+After editing and creating the task group, you need to submit it to the production environment before the tasks it manages can reference the task group's parameter information. The task group also provides a batch submission feature for task nodes.
+
+1. Click the Submit button in the top-right corner. A task group submission dialog will appear, which also supports batch submission of the task list within the task group.
+
+2. In DAG mode, hover over the batch button to reveal the "Batch Submit Tasks" option. Note that this function only batch-submits the tasks within the task group — it does not submit the task group's own parameters and management information to the production environment.
+
+## FAQ
+
+**Q1: Why can't I click the Submit button again after the task group has been submitted?**
+
+After a task group is submitted, if no changes have been made (i.e., the status has not changed to "Submitted with modifications"), it cannot be submitted again. To batch-submit task information within the task group, use one of these two approaches:
+
+Option 1: Submit directly from within each task.
+
+Option 2: In the task group's DAG mode, click "Batch Submit Tasks" under the batch operations menu.
+
+Task group status changes when:
+
+* Tasks are added to or removed from the task group.
+* Task group parameters are added, deleted, modified, or queried.
+
+---
+
+## Related Documentation
+
+- [Task Parameters](task_param.md) — Task-level parameter concepts and configuration, and how they differ from task group parameters
+- [Task Parameter Syntax Reference](task_param_reference.md) — Full syntax for built-in parameters and time expressions
+- [Composite Task](composite_task.md) — How composite task parameters and task group parameters work together
+- [Task Development and Scheduling](task-develop.md) — Referencing task group parameters in individual tasks

package/bin/skills/lakehouse-doc-en/references/task_instance.md

@@ -0,0 +1,82 @@
+# Task Instance Configuration and Its Effect on Instance Execution
+
+The task instance information configuration provides three mechanisms for controlling how instances are handled at different lifecycle stages. The three settings are independent of each other and apply to the **waiting stage**, **the moment an instance enters the running state**, and the **running stage** respectively.
+
+***
+
+## Run Timeout Duration
+
+**Applies to**: Instances in the Running state
+
+If the actual run time of a task instance exceeds the configured value, the system will immediately set that instance to **Failed** status, preventing abnormal tasks from hanging indefinitely and continuously consuming compute resources.
+
+***
+
+## Schedule Wait Duration
+
+**Applies to**: Instances that have reached their scheduled trigger time and are waiting for upstream tasks to complete
+
+Starting from the scheduled trigger time, if an instance remains in the waiting state (neither entering the running state nor finishing) for longer than the configured duration, the system will immediately set that instance to **Failed**, preventing scheduling backlogs caused by upstream tasks taking too long.
+
+> **Example**: A task is scheduled to trigger daily at 01:00, with a schedule wait duration of 2 hours. If the instance is still waiting for upstream at 03:00, the system sets it to Failed.
+
+***
+
+## Delayed Run Skip Duration
+
+**Applies to**: The moment an instance transitions from the waiting state to the running state
+
+The system calculates the difference between the **actual time the instance enters the running state** and the **originally scheduled trigger time**. If the difference exceeds the configured duration, the system performs a **dry-run skip** on that instance and sets its status to **Succeeded**, avoiding meaningless repeated computation on severely delayed instances.
+
+> **Example**: A task is scheduled every 5 minutes, with a skip duration of 6 minutes. The instance scheduled to trigger at 14:05 does not enter the running state until 14:12 due to upstream delays (a delay of 7 minutes > 6 minutes). The system performs a dry-run skip and sets it to Succeeded.
+
+***
+
+## Comprehensive Example: Self-Dependent Periodic Task
+
+**Configuration background**: A self-dependent task scheduled every 5 minutes, with all three timeout settings at **10 minutes**. The first instance (T1) starts running at 14:00 and actually takes 20 minutes to complete.
+
+### Scenario 1: Run Timeout Duration
+
+|              |                         |
+| ------------ | ----------------------- |
+| Time         | Event                   |
+| 14:00        | T1 starts running       |
+| 14:10        | Run time reaches the 10-minute limit; T1 is set to Failed |
+| Subsequent instances from 14:05 onward | All self-dependent subsequent instances are suspended because upstream T1 failed |
+
+![](/.topwrite/assets/image_1780067288681.png)
+
+### Scenario 2: Schedule Wait Duration
+
+|       |                                       |
+| ----- | ------------------------------------- |
+| Time  | Event                                 |
+| 14:00 | T1 starts running normally (not affected by this setting) |
+| 14:05 | T2 reaches its trigger time and enters the waiting-for-upstream (T1) state |
+| 14:15 | T2's wait time reaches the 10-minute limit; T2 is set to Failed. T1 can continue running normally |
+| 14:10 | T3 reaches its trigger time and enters the waiting state; its downstream tasks are suspended because T2 failed |
+| 14:20 | T3's wait time reaches the 10-minute limit; T3 is set to Failed. T1 completes normally |
+
+> The schedule wait duration triggers independently for each instance; T1's normal execution is not affected.
+> ![](/.topwrite/assets/image_1780067342320.png)
+
+### Scenario 3: Delayed Run Skip Duration
+
+|       |                                                    |
+| ----- | -------------------------------------------------- |
+| Time  | Event                                              |
+| 14:00 | T1 starts running normally                         |
+| 14:05 | T2 reaches its trigger time and waits for T1 to complete |
+| 14:20 | T1 completes; T2 enters the running state. Delay = 14:20 − 14:05 = 15 minutes > 10 minutes |
+| 14:20 | T2 is dry-run skipped and set to Succeeded, triggering T3's scheduling |
+
+> A dry-run skip does not execute any actual business logic; it only marks the instance as Succeeded to keep the scheduling chain moving.
+
+***
+
+![](/.topwrite/assets/image_1780067317383.png)
+
+***
+
+^

package/bin/skills/lakehouse-doc-en/references/task_instance_operations.md

@@ -0,0 +1,206 @@
+# Task and Instance Operation
+
+The Operations Center provides management operations for tasks and instances. The tasks controlled by the Operations Center include manually triggered tasks and scheduled tasks, and their corresponding instances, for centralized management.
+
+* Task: A file created in the IDE, which is referred to as a task after being submitted to the Operations Center.
+* Instance: The specific running entity generated by manual execution of a file or scheduled task, referred to as an instance.
+
+## Task Operation
+
+### Task List
+
+Click "Task Operations" in the left navigation to enter the task list page. The task list provides a summary display of tasks in all workspaces under the currently opened service.
+
+![](.topwrite/assets/image_1710658403744.png)
+
+^
+
+#### Task List Content
+
+In the list, you can view key attributes such as task name, task ID, workspace, task status, task type, etc.
+
+#### Task List Operations
+
+In the task list, you can perform quick operations by selecting one or more tasks.
+
+**Single Task Operation**
+
+| Operation Name | Operation Description                                                                                                                                                                                      |
+| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Pause          | Only tasks that are not in the paused state can be operated. After the operation, the scheduling attribute of the task will be set to "Pause Scheduling", i.e., no longer generate and run task instances. |
+| Start          | Only tasks in the paused state can be operated. After the operation, the scheduling attribute of the task will be restored to "Normal Scheduling", i.e., generate and run task instances.                  |
+| Delete         | The operation takes the task offline from the Operations Center and reverts the task to the "Unsubmitted" state of the file.                                                                               |
+
+**Batch Task Operation**
+
+| Operation Name | Operation Description                                                                                     |
+| -------------- | --------------------------------------------------------------------------------------------------------- |
+| Batch Start    | Batch operation of selected tasks, restoring the scheduling attribute of the task to "Normal Scheduling". |
+| Batch Pause    | Batch operation of selected tasks, setting the scheduling attribute of the task to "Pause Scheduling".    |
+
+#### Task List Filtering
+
+At the top of the task list, you can filter according to the attributes of the task as needed.
+
+| Operation Name | Operation Description                                                   |
+| -------------- | ----------------------------------------------------------------------- |
+| More Filters   | Click to expand more filter conditions.                                 |
+| Reset Filters  | Click to reset and clear all given filter conditions.                   |
+| Refresh        | Refresh and re-fetch the list according to the given filter conditions. |
+
+#### Task Details
+
+From the task list, click the link of the task name to enter the details page of the task. On this page, you can view basic information, upstream and downstream dependency graphs, task instances, and code.
+
+**Basic Information**
+
+In this area, you can view the basic information of the task. You can collapse or expand as needed.
+
+^
+
+**Dependency Graph**
+
+On the dependency graph, you can view the direct upstream tasks that the current task depends on, and the direct downstream tasks that depend on it.
+
+![](.topwrite/assets/image_1710658579364.png)
+
+| Operation Name | Operation Description                                                                                                                  |
+| -------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| Search         | By giving the task name or task ID keyword, you can quickly locate the task node on the graph. The matching method used is "Contains". |
+| Refresh        | Click to reload the entire dependency graph.                                                                                           |
+
+^
+
+**Task Instances**
+
+In the task instance area, all task instances generated by the current task in all time ranges are displayed.
+
+![](.topwrite/assets/image_1710658863166.png)
+
+For a single task instance, basic control operations can be performed:
+
+| Operation Name | Operation Description                                                                            |
+| -------------- | ------------------------------------------------------------------------------------------------ |
+| Stop           | For instances that are not running, you can stop them.                                           |
+| Rerun          | For instances that have reached the end state, you can rerun them, i.e., run the instance again. |
+
+**Code**
+
+The node code area displays the latest version of the code for the current task.
+
+![](.topwrite/assets/image_1710658900006.png)
+
+**Task Operation**
+
+On the task details page, you can pause, start, and delete this task. The meaning and function are the same as the operations provided in the list.
+
+| Operation Name | Operation Description                                                                                                                                                                                      |
+| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Pause          | Only tasks that are not in the paused state can be operated. After the operation, the scheduling attribute of the task will be set to "Pause Scheduling", i.e., no longer generate and run task instances. |
+| Start          | Only tasks in the paused state can be operated. After the operation, the scheduling attribute of the task will be restored to "Normal Scheduling", i.e., generate and run task instances.                  |
+| Delete         | The operation takes the task offline from the Operations Center and reverts the task to the "Unsubmitted" state of the file.                                                                               |
+
+## Instance Operation
+
+### Instance List
+
+Click "Instance Operations" in the left navigation to enter the instance list page. The instance list provides a summary display of task instances in all workspaces under the currently opened service instance.
+
+![](.topwrite/assets/image_1710658772113.png)
+
+#### Instance List Content
+
+In the list, you can view key attributes such as instance ID, corresponding task name, instance type, workspace, instance status, scheduled time, execution time, and completion time.
+
+#### Instance List Filtering
+
+At the top of the instance list, you can filter according to the attributes of the task as needed.
+
+| Operation Name | Operation Description                                            |
+| -------------- | ---------------------------------------------------------------- |
+| More Filters   | Click to expand more filter conditions.                          |
+| Reset Filters  | Click to reset and clear all given filter conditions.            |
+| Refresh        | Refresh and re-fetch the list according to the given conditions. |
+
+#### Instance List Operations
+
+In the instance list, you can perform quick operations by selecting one or more task instances.
+
+![](.topwrite/assets/image_1710658988417.png)
+
+^
+
+#### Single Task Instance Operation
+
+| Operation Name | Operation Description                                                                                                                                                                                                                                                                                                                                               |
+| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Pause          | Only task instances that are not in the paused state can be operated. After the operation, the scheduling attribute of the task instance will be set to "Pause Scheduling", i.e., no longer schedule and run the task instance.                                                                                                                                     |
+| Resume         | Only task instances in the paused state can be operated. After the operation, the scheduling attribute of the task instance will be restored to "Normal Scheduling", i.e., run the task instance according to the set scheduling time.                                                                                                                              |
+| Terminate      | Only running task instances can be operated. After the operation, the running task instance will be terminated and the task instance status will be set to failure.                                                                                                                                                                                                 |
+| Rerun          | Only completed task instances can be operated. After the operation, the task instance will be rerun.                                                                                                                                                                                                                                                                |
+| Set Success    | Only failed task instances can be operated. After the operation, the task instance will be forcibly set to success. This can be used in emergency operations scenarios. When it is judged that even if the current task instance fails, it does not affect the data correctness of the downstream task, it can unblock the running of the downstream task instance. |
+| Set Failure    | Only successful task instances can be operated. After the operation, the task instance will be forcibly set to failure.                                                                                                                                                                                                                                             |
+
+#### Batch Task Instance Operations
+
+| Operation Name | Operation Description                                                                                 |
+| -------------- | ----------------------------------------------------------------------------------------------------- |
+| Pause          | Same as single operation. Note that only task instances that are not in pause status can be operated. |
+| Resume         | Same as single operation. Note that only task instances that are in pause status can be operated.     |
+| Terminate      | Same as single operation. Note that only running task instances can be operated.                      |
+| Rerun          | Same as single operation. Note that only completed task instances can be operated.                    |
+| Set Success    | Same as single operation. Note that only failed task instances can be operated.                       |
+| Set Failure    | Same as single operation. Note that only successful task instances can be operated.                   |
+
+### Instance Details
+
+From the instance list, click on the link of the instance ID to enter the detail page of this task instance. On this page, you can view basic information, upstream and downstream dependency graphs, task instances, and code.
+
+#### Basic Information
+
+In this area, you can view the basic information of the task instance.
+
+![](.topwrite/assets/image_1710659067180.png)
+
+^
+
+#### Dependency Graph
+
+On the dependency graph, you can view the direct upstream task instances that the current task instance depends on, to quickly judge whether the current task instance can be scheduled normally.
+
+![](.topwrite/assets/image_1710659193306.png)
+
+##### Operations of Dependency Graph
+
+| Operation Name | Operation Description                                                                                                                              |
+| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Search         | By giving the task name or instance ID keyword, you can quickly locate the task instance node on the graph. The matching method used is "contain". |
+| Refresh        | Click to reload the entire dependency graph.                                                                                                       |
+
+On the DAG graph, you can switch to choose to tile nodes directly or group them together, such as aggregating instance nodes with the same status into the same group.
+
+![](.topwrite/assets/image_1710659245739.png)
+
+#### Code
+
+The code area will display the corresponding version of the code used by the current task instance at runtime. Please note that this is the code used when the task instance is executed, not necessarily the latest version of the task.
+
+![](.topwrite/assets/image_1710659285422.png)
+
+#### Execution Log
+
+The execution log area will display all logs of the current instance execution, including logs generated after the task instance is rerun. Click on the + icon on the left side of the list to expand and view detailed content.
+
+![](.topwrite/assets/image_1710659363263.png)
+
+#### Operation Log
+
+The operation log area will display the operation records of the current instance.
+
+![](.topwrite/assets/image_1710659429272.png)
+
+### Instance Operations 
+
+On the task instance detail page, you can pause, resume, terminate, rerun, and set success operations for this task instance. The meaning and function are the same as the operations provided in the list.
+
+![](.topwrite/assets/image_1710659494175.png)

package/bin/skills/lakehouse-doc-en/references/task_param.md

@@ -0,0 +1,130 @@
+# Task Parameters
+
+> ⚠️ **Note**: The parameter feature is currently in limited rollout and is only available to select users. If you configure parameters and run a task but the parameters are not substituted, your account is not yet in the rollout scope. Use the verification method at the end of this page to confirm whether your account is supported.
+
+## What are task parameters
+
+In day-to-day data development, you often encounter situations like these:
+
+- Processing the previous day's data: `WHERE dt = '2023-09-21'`
+- Aggregating last month's data: `WHERE month = '2023-08'`
+- Querying data for a specific city: `WHERE city = 'Shanghai'`
+
+If you hard-code dates, cities, and other values directly in your code, the task cannot adapt dynamically at runtime. **Task parameters** are designed to solve this — use `${parameter_name}` as a placeholder in your code, and the system automatically substitutes the actual value at runtime.
+
+**Core value**: dynamic substitution, flexible configuration, define once and use in multiple places, change parameter values without touching your code logic.
+
+### Basic Concepts
+
+| Category | Concept | Meaning | Example |
+| ---- | ---- | ---- | ---- |
+| Parameter definition | Custom parameter | Referenced in code using `${parameter_name}` | `${yesterday}` |
+| Parameter value | Constant | A fixed string or number | `Shanghai`, `1234` |
+| Parameter value | System built-in parameter | System-provided dynamic values, such as the scheduled time | `sys_plan_datetime` |
+| Parameter value | Time expression | Format and offset calculations based on the scheduled time | `$[yyyy-MM-dd, -1d]` |
+| Parameter value | Built-in time function | Handles complex time calculations like first day of month, Monday, etc. | `first_day_of_month()` |
+
+---
+
+## Quick Start
+
+**Step 1: Use parameters in your code**
+
+```sql
+SELECT * FROM sales_table WHERE city = '${city}' AND dt = '${yesterday}';
+```
+
+**Step 2: Configure parameter values**
+
+Click the "Parameters" button. The system automatically detects the `city` and `yesterday` parameters. Assign values to them:
+
+- `city` = `Shanghai`
+- `yesterday` = `$[yyyy-MM-dd, -1d]`
+
+**Step 3: Run and verify**
+
+Click "Run". The system substitutes the parameters before executing (assuming today is 2023-09-22):
+
+```sql
+SELECT * FROM sales_table WHERE city = 'Shanghai' AND dt = '2023-09-21';
+```
+
+**Key points**:
+- The parameter format is always `${parameter_name}`. Parameter names may only contain letters, digits, and underscores.
+- You cannot reference built-in parameters (such as `sys_biz_day`) directly in code — you must first assign them to a custom parameter, then reference the custom parameter.
+- Add quotes in SQL yourself when needed: `'${city}'`
+
+---
+
+## Parameter Types and Scope
+
+### Task Parameters
+
+Scoped to the current task only. Use these for configuration that is unique to a single task.
+
+**How to create**: type `${parameter_name}` in your script and the system detects it automatically, or click the "Parameters" button to create one manually.
+
+![](.topwrite/assets/image_1740658949338.png =700)
+
+| Field | Description | Example |
+| ---- | ---- | ---- |
+| Parameter name | Unique identifier for the parameter | `city`, `yesterday` |
+| Value source | Select "Task" or "Task Group" | Task |
+| Parameter value | The actual value or expression | `Shanghai`, `$[yyyy-MM-dd, -1d]` |
+| Encrypt value | When checked, the value is masked | Use for passwords and other sensitive data |
+| Ignore | When checked, no substitution is performed | Treats `${var}` as literal text |
+
+### Task Group Parameters
+
+Scoped to all tasks within the task group. Use these for configuration shared across multiple tasks (such as database names or environment identifiers).
+
+On the task group page, click "Parameters" → "New" to create one. When using a task group parameter in a specific task, explicitly switch the value source to "Task Group".
+
+![](/.topwrite/assets/image_1760699887513.png =680)
+
+```sql
+-- Task group parameter: db_name = warehouse_prod
+-- Task A and Task B share the same parameter
+SELECT * FROM ${db_name}.table_a;
+SELECT * FROM ${db_name}.table_b;
+```
+
+---
+
+## Parameter Behavior by Run Mode
+
+### Manual run (clicking the "Run" button)
+
+A dialog prompts you to enter parameter values. The values apply to this run only and do not affect the saved parameter configuration. Useful for debugging and validation.
+
+![](/.topwrite/assets/image_1761284431760.png =680)
+
+### Scheduled run
+
+Uses the saved parameter configuration and dynamically calculates parameter values based on the scheduled time. Use this in production.
+
+---
+
+## Appendix: How to verify full parameter support
+
+Run the following in a SQL task:
+
+```sql
+SELECT '${lastDay}' AS lastDay;
+```
+
+Parameter configuration: `lastDay` = `add_days('yyyy-MM-dd', -1)`
+
+If the result is yesterday's date (e.g., `2023-11-11`), your account is in the rollout scope and full parameter functionality is supported. If `${lastDay}` is not substituted, it is not yet supported.
+
+---
+
+## Related Documentation
+
+| Document | Description |
+| ---- | ---- |
+| [Task Parameter Syntax Reference](task_param_reference.md) | Complete syntax and quick-reference for system built-in parameters, time expressions, and built-in time functions |
+| [Task Parameter Examples](task_param_examples.md) | Complete business scenario examples for daily reports, monthly reports, weekly reports, timestamp queries, and FAQ |
+| [Task Development and Scheduling](task-develop.md) | Creating, scheduling, and operating SQL tasks in Studio |
+| [Workflow (Composite Task)](composite_task.md) | Orchestrate multiple parameterized tasks into a DAG with unified scheduling |
+| [Python Task](python-task.md) | Using parameters in Python tasks |