2.4 Environment Variables & Connection References

Microsoft Power Platform Developer Associate PL-400

Track your progress as you read

Finished sections get a check mark.

1 Introduction, Exam Overview & Developer Toolchain

0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow

2 Create a Technical Design

1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations

3 Build Power Platform Solutions

2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools

4 Implement Power Apps Improvements

3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance

5 Extend the User Experience

4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component

6 Extend the Platform: Dataverse Plug-ins & Custom APIs

5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events

7 Extend the Platform: Custom Connectors

6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation

8 Extend the Platform: Platform APIs & Azure Functions

7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities

9 Extend the Platform: Power Automate Cloud Flows

8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals

10 Develop Integrations

9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message

11 Exam Readiness & Practice

10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan

2.4 Environment Variables & Connection References

Key Takeaways Explain This Topic AI

An environment variable's definition, with an optional default value, ships inside the solution; its current value is set per environment and is not part of the package.

Connection references let a cloud flow or canvas app's connector connection be bound separately in each environment at import time.

Secret-type environment variables reference a value stored in Azure Key Vault so the secret itself is never stored in Dataverse.

Unattended flows should bind connection references to an application user's connection rather than a named person's credentials.

Deployment settings JSON files let a CI/CD pipeline set environment variable values and connection reference bindings automatically during import.

Last updated: July 2026

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.

Data type Example use
Text An API base URL
Number A retry threshold or batch size
Boolean (Two Options) A feature flag
JSON A structured configuration block consumed by a plug-in or flow
Data source A reference to a specific Dataverse record, such as a config row
Secret A reference to a value stored in Azure Key Vault, so the secret itself is never stored in Dataverse

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."