Global parameters¶

A global parameter is a named value you write once and reuse everywhere: a tenant id, an API base URL, a container name, a password. Scripts, queries and commands reference it as a token — {$AppSecret} — and the execution engine swaps in the real value at the moment a task runs.

Two things follow from that. You change a value in one place instead of hunting through twenty packages, and a secret never has to be typed into a script that someone can read.

On cloud deployments they are managed in TDP under Settings → Global Parameters.

Before you start¶

• The Global Parameters tab is visible to global administrators and to Workspaces-group administrators. If you cannot see it under Settings, you do not have that role.
• Inserting a parameter into a script is open more widely — Contributor or higher on a workspace, dataset or package.
• Know whether the value is a secret before you create it. Encryption can be turned on later, but the platform will never show you the old value again, so you have to retype it.

Create a parameter¶

1. Open Settings and select the Global Parameters tab.

   

2. Click Create. The Create Global Parameter dialog opens.

3. Enter a Name — the bare name, without braces. The dialog shows you the token it becomes, so AppSecret becomes {$AppSecret}.

4. Enter a Value, and optionally a Description.

   

5. Turn on Encrypt value if the value is a secret.

   

   See Encrypted values — the behaviour is not symmetric, and it is worth reading before you save.

6. Click Create.

Use a parameter¶

Two ways, depending on where you are.

From the list¶

Click the copy icon next to a parameter's name to put its {$Name} token on the clipboard, then paste it into a script, query or command.

From the script editor¶

PowerShell packages have an {$} Insert Parameter button above the script editor:

1. Click into the script editor, then click {$} Insert Parameter.
2. Type in the search box to filter by name.
3. Click the parameter, or use ↑/↓ and press Enter. The exact token is inserted at the cursor.

Encrypted parameters show a padlock and no value; system parameters show a system badge. In every case only the token is inserted — never the value. Tokens already present in your script are highlighted.

Where tokens are accepted¶

• Package working-directory and command fields
• Queries and compare queries
• Dimensions
• Schedule, process and object-group extra parameters

Encrypted values¶

Encryption is a one-way door from the screen's point of view. The platform stores the value and never renders it back, which produces three behaviours worth knowing in advance:

• Editing an encrypted parameter — leave Value blank to keep the value you have. Anything you type replaces it.
• Turning encryption off — the platform cannot decrypt the old value back onto the screen. Type a new value with Encrypt value switched off. Saving with a blank value instead clears the parameter; a warning is shown first, and reopening it afterwards tells you it has no value.
• Length — an encrypted value is capped at 143 characters of plaintext. A longer one is rejected with a message, not truncated.

At run time the real value is handed to your script or command — that is the point of it. Treat a secret as an input: pass it to a command or a connection, and keep it out of anything your task writes to its own output.

Secrets do not reach the execution log¶

When a command-line execution uses a global parameter, the execution log records the parameter reference — {$MyPassword} — rather than what it resolved to. Logs are retained in history indefinitely and are visible to anyone who can view a run, so this holds on every path: success, a failing exit code, a timeout, a cancellation and a failure to start.

The exception is a command that prints its own values — if it echoes its arguments or logs its own configuration, that output still appears, because it is the command's output rather than something the platform composed. Gateway-dispatched runs are covered on both sides of the hop.

Before you delete or rename¶

Deleting or renaming a parameter breaks every script that still references the old token, so the platform checks first and shows you what it found.

• Deleting — the confirmation lists, per parameter, the packages, queries and datasets still using its token, with the environments each applies to (Package: Nightly load (DEV, PROD)). Deleting is never blocked. The list is there so the decision is informed, not to stop you.
• Renaming — the same check runs against the old name while you type the new one, and Save waits briefly with "Checking where {$Name} is used…".
• The check is best-effort and says so. A parameter used only in a dataset that exists in TDP and has not been published is not listed, because tokens are not substituted there yet.
• If the check itself fails you are told — "The usage check could not be completed" — rather than shown an empty list that looks like a clean bill of health.

System parameters¶

Four parameters are built in, badged system, and cannot be edited or deleted. They have no stored value; the execution engine fills them in per run.

{$__ExecId} is the useful one in practice — write it into your own log lines and a failed run in the Executions list can be matched to your script's output.

Parameters carried over from ODQ Desktop¶

On cloud deployments:

• Parameters created in ODQ Desktop appear in TDP automatically, encrypted ones included, and existing tasks resolve the same values. Nothing has to be re-entered.
• Parameters whose names do not satisfy TDP's naming rules — names starting with __, or containing dots, symbols, or leading, trailing or doubled spaces — keep working. They display as they are and stay value-editable. Only new names, created or renamed, have to satisfy the rules.
• Opening the Global Parameter screen in ODQ Desktop directs you to manage them in TDP. The Desktop token-inserter still works while you author a package there; it is creating and editing the parameters themselves that is done in TDP.

Best practices¶

Name for the thing, not the environment. {$DataLakeContainer} with a different value per environment beats {$ProdContainer} and {$DevContainer} referenced by different scripts.

Encrypt anything you would not paste into a support ticket. The 143-character cap is generous for a key or a password and tight for a certificate — check before you design around it.

Put {$__ExecId} in your log output. It is the only reliable way to line up what your script printed with the run that printed it.

Rename rarely. The usage check is best-effort, so a rename can leave a token unresolved somewhere it did not find. Creating a new parameter and retiring the old one after is safer.

Troubleshooting¶

The token appears literally in the output instead of a value. The parameter does not exist, or the name does not match. Substitution is case-sensitive in the execution engine even though name uniqueness is case-insensitive — so {$apisecret} will not resolve a parameter named ApiSecret, and you cannot create both. Copy the token from the list rather than typing it.

"The usage check could not be completed." The delete or rename dialog could not reach the check. The operation is still allowed; you just have no list. Retry before deciding.

A value saved as empty. You turned encryption off and left the value blank. That clears the parameter — the warning at save time is the only notice. Reopen it and type the value again.

An encrypted value is rejected on save. It is longer than 143 characters of plaintext.

I cannot see the Global Parameters tab. It is gated to global administrators and Workspaces-group administrators. A deep link to ?tab=global-parameters without that role shows "You don't have access to that settings tab."

Reference¶

Fields¶

Permissions¶

Related¶

• Global Parameters in ODQ Desktop — the on-premises path, and the article this page supersedes for cloud customers
• Create a PowerShell package — where the Insert Parameter picker lives
• Packages in the Timextender Data Platform
• What's new in 26.3