2.4 Environment Variables & Connection References

Environment Variables & Connection References

Quick Answer: Environment variables externalize configuration values, and connection references externalize connector connections, so a managed solution deploys unmodified across dev, test, and production. Each variable's definition ships inside the solution while its current value is set per environment; each connection reference ships inside the solution while the bound connection itself is chosen per environment at import time.

The ALM Problem They Solve

Hard-coding an environment-specific value - a SharePoint site URL, an API endpoint, a numeric threshold, a secret - directly inside a plug-in, flow, or Power Fx formula means that value has to be manually edited every time the solution moves from dev to test to production. Environment variables and connection references exist specifically to remove that manual step from ALM, so a managed solution import behaves like a code deployment with externalized configuration.

Environment Variables

An environment variable is a Dataverse record split into two parts on purpose:

• Environment Variable Definition - the schema (name, data type, optional default value) - ships inside the solution and moves with it on every import.
• Environment Variable Value - the actual, environment-specific value - is not part of the solution package. It's set once per environment, either in the target environment's maker portal or scripted through pac or the Dataverse Web API during a pipeline run, and it persists across re-imports of the same solution.

Because the definition, with its optional default value, travels with the solution but the current value doesn't, a developer can import the same managed solution into Dev, Test, and Production and simply set three different current values. There is no need to edit the solution's components between environments, and no risk of a test endpoint accidentally shipping to production inside the package itself.

Connection References

A connection reference solves the same problem for connections - the authenticated link a cloud flow or canvas app uses to call a connector such as Dataverse, SharePoint, Outlook, or a custom connector. Instead of a flow embedding one specific user's live connection, which breaks the moment that user's credentials change or simply doesn't exist in the target environment, the flow points at a connection reference, and the actual connection is bound per environment at import time - the importer is prompted to select or create the connection that reference should use in that environment.

• Connection references ship inside the solution, just like environment variable definitions; the bound connection itself is environment-specific and is not part of the package.
• For unattended flows and integrations, the connection behind a connection reference should point to an application user or service principal rather than a named human's credentials, so the flow doesn't break when that person leaves or changes their password - the same least-privilege application-user pattern used for security roles applies here.
• Using connection references, rather than embedded connections, is required for a flow to be portable through a managed pipeline at all - Dataverse blocks solution export of many maker-portal flows that use a raw, unreferenced connection.

Working with Both in CI/CD

In an automated pipeline, environment variable current values and connection reference bindings are typically supplied through a deployment settings JSON file passed to the import step, or set through pac and Power Platform Build Tools parameters, so no manual maker-portal step is needed between "solution imported" and "solution fully configured" in the target environment. This is the mechanism that makes the pipelines and CI/CD approaches covered next in this chapter possible without a human touching each environment after every deployment.

Exam Angle

Expect questions distinguishing environment variables from connection references by what each parameterizes - a value versus a connection - and questions about why a hard-coded URL or embedded connection is the wrong design choice for a solution that will be deployed across dev, test, and prod. The answer is almost always "replace it with an environment variable" or "replace it with a connection reference."