Power Platform environment variable

What is a Power Platform environment variable?

A Power Platform environment variable holds a piece of configuration that changes from one environment to the next, so apps and flows can point at it instead of hard-coding a test or production value. A SharePoint site address, an API base URL, a notification mailbox, or a feature toggle are typical examples.

Because the reference stays the same while the value changes, the same solution can move through development, test, and production without edits to the app or flow itself. The variable lives inside a solution as a component, next to the apps, flows, and tables it supports.

An environment variable is made of two parts: a definition that travels with the solution, and a value that is usually set in the target environment during deployment.

Definition, default value and current value

The definition carries the schema name, display name, and data type, plus an optional default value. Think of it as the configuration contract the solution ships with.

The current value overrides the default for one specific environment. If no current value is set, a consumer can fall back to the default. A value cannot exist without a definition, and each definition holds one value at a time.

Keep production current values out of the release package. Let the deployment pipeline or an administrator supply them in the target environment, so the exact artefact you tested is the one that reaches production.

Supported value types

You choose from a fixed set of data types: text, decimal number, yes/no, JSON, data source, and secret. What each consumer can actually read back varies, so validate the value where you use it.

A JSON variable can carry structured settings, but nothing checks its shape for you. A data source variable helps you point a connector at the right table or site per environment. The secret type works differently: it links to Azure Key Vault, the value is fetched at runtime, and it is not written to run history. A plain text variable holding a password stays plain text no matter how you name the field.

An example in a flow

An onboarding flow files documents in SharePoint. In development it writes to a test site; in production it writes to the official HR site.

The solution carries a definition for the site address and a connection reference for the SharePoint connection. At deployment both are bound to the target environment, while the flow definition stays byte-for-byte the same. That is what lets a test prove the exact artefact bound for production behaves correctly against different configuration.

Environment variable versus connection reference

An environment variable supplies a value or a data source parameter. A connection reference points at the Power Platform connection an action authenticates through. A URL and an identity are separate concerns, and one flow often needs both: the variable says which site to use, the connection reference says under which connection the action runs.

Avoid personal production connections here. Use service identities with clear ownership and least privilege, so a flow does not quietly run under one person's individual account.

What to watch out for with environment variables

Secrets need real protection. Non-secret configuration can be visible to authorised makers and admins, but API keys, client secrets, and passwords belong in the linked Key Vault, reachable only by the identity that runs the flow. Check that the value does not resurface in error messages or run history after it is retrieved.

Schema changes are breaking. Renaming a schema name or switching a data type after components already use the variable can break dependencies and existing values. Treat those changes as versioned, not casual.

Missing values should fail loudly. Document which variables are required, who owns them, and what the defaults mean. Let a deployment stop when a required value is absent rather than falling back silently to the wrong default. After import, confirm which value is actually active and run a quick functional check, because a successful solution import does not prove the configuration is right.