Skip to main content
Variables let you keep a single pipeline definition while changing behavior by context—environment, tenant, or run-time input. You reference variables in node configuration fields instead of hard-coding values that differ between development and production.

​
Pipeline variables vs global variables

Pipeline variables belong to one pipeline (or a closely related set of graphs you treat as one product). Use them for values that are specific to that flow: landing-zone paths, topic names, feature flags for that job, or default batch sizes.Typical properties:
  • Name: Identifier you use in expressions (for example, landing_bucket).
  • Default value: Used when nothing else overrides the variable.
  • Type or validation (when exposed in the UI): Reduces misconfiguration before run time.
Pipeline variables travel with the pipeline definition when you export, template, or version it in Git—so reviewers see both the graph and the parameter surface.

​
Variable syntax and usage

You insert variables into text fields that support interpolation—connection parameters, paths, SQL fragments, JSON templates, and similar. Common patterns: 
{{ variable_name }}
Some fields accept expressions that combine literals and variables: 
s3://{{ env_bucket }}/{{ dataset }}/year={{ run_year }}/
Guidelines:
  • Use descriptive names: raw_sales_bucket beats b1.
  • Avoid secrets in variables when your organization provides a secret store or credential references; store credentials in connections and pass non-secret locators via variables.
  • Document required variables in the pipeline description or template readme so consumers know what they must set.
If a node offers both a “full text” field and structured sub-fields, prefer structured fields when available. They validate types earlier and produce clearer errors than a single free-form string.

​
Environment-specific overrides

On plans with environments, you map the same pipeline to development, staging, production, or custom stages. Environment-specific variable overrides replace defaults when you deploy or run in that environment. Typical workflow:
  1. Define pipeline variables with safe defaults (often dev-like values).
  2. In each environment, set overrides for buckets, databases, API base URLs, and batch limits.
  3. Run or schedule the pipeline in an environment; Planasonix resolves variables using that environment’s layer.
Duplication drifts: one copy gets a fix, the other does not. Variables plus environments keep one graph, one review story, and a clear matrix of “what changes between stages.”
When Git integration is enabled, variable names and default metadata often live in versioned artifacts, while secret values and some override values may remain in the managed platform. That split supports PR review without leaking production credentials into the repository.

Environments

Deploy across stages with consistent override behavior.

Git integration

Version pipeline definitions alongside application code.