Configuring Dataverse Environment Variables in Model-Driven App Solutions: Managing Connection References, Default Values, and Deployment-Time Overrides Across Environments
Environment variables are the key to building Power Platform solutions that deploy cleanly across dev, UAT, and production without manual edits. This deep-dive lesson covers the full lifecycle: creating typed variables, managing the default/current value split, binding connection references, and injecting overrides at deployment time using Power Platform CLI and deployment settings files.
⚡ Practitioner23 min readSep 22, 2026Updated Sep 22, 2026
Configuring Dataverse Environment Variables in Model-Driven App Solutions: Managing Connection References, Default Values, and Deployment-Time Overrides Across Environments
Introduction
Picture this: your team has spent three weeks building a sophisticated model-driven app for a field services company. The app pulls configuration data from a SharePoint list, calls an external REST API for weather routing, and sends notifications through a shared inbox. Everything works perfectly in the development environment. Then you promote the solution to UAT, and the entire thing points back at the development SharePoint site, the dev team's email inbox, and a sandbox API endpoint that doesn't exist in the UAT tenant. You're back to manually hunting through flows and connections, editing hardcoded values one by one — hoping you haven't missed anything.
Environment variables exist precisely to prevent that scenario. They give you a structured, solution-aware way to externalize configuration — API endpoints, SharePoint site URLs, feature flags, numeric thresholds, connection references — so that when you move a solution from dev to UAT to production, deployment-time values slot in cleanly without touching your app logic. This isn't just convenient; it's the difference between a maintainable ALM (Application Lifecycle Management) pipeline and a configuration nightmare that only the original developer can navigate.
By the end of this lesson, you'll know how to design, configure, and deploy environment variables across the full Power Platform ALM lifecycle. You'll understand the difference between default values and current values, how connection references relate to environment variables, and how to automate override injection at deployment time using deployment pipelines and the CLI.
What you'll learn:
The architecture of environment variables: definitions, current values, and solution packaging behavior
How to create environment variables for each supported data type, including connection references
How to set default values for development and override them in downstream environments
How to export, import, and inject environment variable values using Power Platform CLI and deployment pipelines
How to consume environment variables inside Power Automate flows, Power Apps formulas, and Dataverse plug-in configurations
Common mistakes that cause deployment surprises and how to diagnose them
A Power Platform environment with a Dataverse database
The Power Platform CLI installed (pac version 1.20 or later)
At least two environments (dev + UAT or dev + production) to practice the deployment scenarios
Maker or System Customizer permissions in both environments
What Environment Variables Actually Are (Under the Hood)
Before you configure anything, you need a mental model of what you're actually working with. Environment variables in Dataverse aren't magical — they're just records in two specific system tables.
environmentvariabledefinition stores the variable itself: its schema name, display name, data type, description, and the default value. This table lives inside your solution. When you export a solution, the definition travels with it.
environmentvariablevalue stores the current value — the actual value that overrides the default in a given environment. This is the key nuance. The current value record is intentionally excluded from managed solution exports by default, because it's meant to be environment-specific.
This separation is deliberate. Your default value says "in dev, this SharePoint site URL is https://contoso.sharepoint.com/sites/FieldServicesDev." Your current value in production says "actually, use https://contoso.sharepoint.com/sites/FieldServicesProd." The definition travels in the solution. The current value either gets set manually after import or gets injected by your deployment pipeline.
Key insight
If you don't set a current value in a target environment, the system falls back to the default value from the definition. This is safe behavior for development but dangerous for production — you need an explicit strategy for ensuring current values exist before the app goes live.
When a Power Automate flow or canvas app reads an environment variable, it reads the current value if it exists, and falls back to the default. If neither exists, the variable returns null/blank — and depending on how your flow is written, that can cause silent failures or runtime errors.
Creating Environment Variable Definitions
You create environment variable definitions inside a solution — never directly in the environment without a solution context. Here's why: if you create them outside a solution, they end up in the Default Solution, which you can't cleanly manage or transport.
Step-by-Step: Adding an Environment Variable to a Solution
Navigate to make.powerapps.com, select your target development environment, and open your solution (not the Default Solution). From the solution's Objects panel on the left, click New and select More → Environment variable.
The creation dialog asks for:
Display name: Human-readable name you'll see in the maker UI. Use something descriptive: Field Services SharePoint Site URL.
Name: The schema name, prefixed with your publisher prefix. If your publisher prefix is contoso, this becomes contoso_FieldServicesSharePointSiteURL. You can't change this after creation.
Data type: Text, Number, Boolean, JSON, Data source, or Secret.
Default value: The value that travels with the solution definition. For dev, put your dev-environment value here.
Current value: Optionally set an environment-specific override right now. Leave this blank during development — you'll inject it at deployment time.
Description: Don't skip this. Six months from now, someone will need to know what this variable drives.
Click Save. The environment variable definition is now part of your solution.
Choosing the Right Data Type
Text covers most use cases: URLs, email addresses, identifiers, API keys (though for secrets, use Secret instead). Maximum 2000 characters.
Number is a decimal type — useful for thresholds like MaxRetryAttempts, InvoiceApprovalThreshold, or PageSizeDefault.
Boolean is your feature flag type. Use it for EnableBetaFeatures, UseNewApprovalFlow, or MaintenanceModeActive. Values are true or false.
JSON is powerful and underused. It lets you store structured configuration objects — think an array of email recipients, a mapping of region codes to managers, or a complex routing configuration. The value is just a string that your flow or app parses as JSON.
Data source is specifically for connector-based connections, which we'll cover in the Connection References section below.
Secret integrates with Azure Key Vault. The environment variable stores a reference to a Key Vault secret, not the secret value itself. This is the right choice for API keys, passwords, and tokens in production scenarios.
Warning
Don't use Text type for secrets, even if you're tempted by its simplicity. Text values are stored in plaintext in the Dataverse environmentvariablevalue table and are visible to anyone with System Administrator access. Use Secret type backed by Key Vault for anything sensitive in production.
Managing Default Values vs. Current Values
This is where most teams get burned, so let's be precise.
Default Values Travel With the Solution
When you export your unmanaged solution and import it as a managed solution in UAT, the environmentvariabledefinition record travels with it — including the default value you set in dev. The default value is what gets deployed.
This is intentional. The default value is your safety net. If something goes wrong with your deployment pipeline and no current value gets injected, the app still runs — just against the default (probably dev-pointing) configuration. That's better than null, though clearly not right for production.
Current Values Stay in the Environment
The environmentvariablevalue record is not included in managed solution exports by default. When you import a managed solution, any existing current values in the target environment are preserved. New current values don't come in from the export.
This means:
First import to a fresh UAT environment: no current values exist, so defaults apply.
You then set current values in UAT manually or via CLI.
On the next solution upgrade import, those current values are preserved — the import doesn't overwrite them.
Note
If you're importing an unmanaged solution (which you should only be doing in your dev environment), the solution can carry current values. This is a source of confusion — be intentional about which solution type you're using in which environment.
Setting Current Values After Import (Manual Approach)
After importing your managed solution into UAT, navigate to make.powerapps.com in the UAT environment, open the managed solution, find the environment variable, and edit it. You'll see the Current value field is blank. Enter the UAT-specific value here.
This works fine for small teams with one or two environments. It doesn't scale. For any serious ALM pipeline, you need to inject values programmatically.
Injecting Current Values with Power Platform CLI
The Power Platform CLI (pac) gives you precise control over environment variable values at deployment time. This is how you build repeatable, automated deployments.
Authenticating and Targeting an Environment
# Authenticate with a service principal (recommended for CI/CD)
pac auth create --name UAT \
--environment "https://contoso-uat.crm.dynamics.com" \
--applicationId "00000000-0000-0000-0000-000000000001" \
--clientSecret "your-secret-here" \
--tenant "your-tenant-id"
# Switch to the UAT auth profile
pac auth select --name UAT
Listing Environment Variables in a Target Environment
# List all environment variable definitions in the target environment
pac env list-variables --environment "https://contoso-uat.crm.dynamics.com"
This gives you the schema names and current values, which you'll need for the next step.
Setting a Current Value via CLI
# Set a text environment variable current value
pac env update-variable \
--environment "https://contoso-uat.crm.dynamics.com" \
--name "contoso_FieldServicesSharePointSiteURL" \
--value "https://contoso.sharepoint.com/sites/FieldServicesUAT"
# Set a boolean environment variable
pac env update-variable \
--environment "https://contoso-uat.crm.dynamics.com" \
--name "contoso_EnableBetaFeatures" \
--value "false"
# Set a number environment variable
pac env update-variable \
--environment "https://contoso-uat.crm.dynamics.com" \
--name "contoso_InvoiceApprovalThreshold" \
--value "5000"
Using a Deployment Settings File
For production deployments, hardcoding values in shell scripts is fragile. The better approach is a deployment settings JSON file, which captures all environment-specific overrides in one place.
The --settings-file flag applies all environment variable values and connection reference mappings in a single atomic operation during import. This is the pattern you want for any serious CI/CD pipeline — GitHub Actions, Azure DevOps, or Power Platform Pipelines.
Tip
Generate a starter deployment settings file from your solution using pac solution create-settings --path "./contoso-fieldservices-1.0.0.zip" --settings-file "./deployment-settings-template.json". This outputs a template with all the environment variables and connection references from the solution, with blank values for you to fill in. Commit the template to your repo and maintain environment-specific versions (e.g., uat-settings.json, prod-settings.json) — never commit the prod settings file with real secrets to a public repo.
Connection References: The Special Case
Connection references deserve their own section because they're a distinct but related concept that trips up almost everyone the first time.
What a Connection Reference Is
A connection reference is a solution component that acts as a pointer to a connector connection. Instead of a flow or app being directly bound to a specific connection (which would make it environment-specific), it binds to a connection reference, which then maps to the actual connection in each environment.
Think of it like this: your flow says "I need a SharePoint connection." The connection reference says "in dev, the SharePoint connection to use is [Alice's dev connection]. In UAT, it's [the UAT service account connection]." The flow itself doesn't change — only the connection reference mapping changes per environment.
Creating a Connection Reference
When you add a SharePoint or Dataverse action to a Power Automate flow inside a solution, the maker experience automatically offers to create a connection reference. Give it a meaningful name: Field Services SharePoint Connection. The prefix from your publisher gets applied: contoso_FieldServicesSharePointConnection.
You can also create connection references manually: in your solution, click New → More → Connection Reference, select the connector type, and optionally bind a connection right now (for your dev environment).
What Gets Exported vs. What Stays
The connection reference definition (schema name, connector type, display name) travels in the solution export. The connection binding — the actual connection ID that maps to a specific user's or service account's credentials — does not travel. This is by design: connection credentials are environment-specific.
When you import the solution into UAT, the connection reference arrives without a connection bound. Power Automate flows that depend on it will be suspended (turned off) until you bind a connection.
Binding Connection References After Import
Manual approach: After import, navigate to the solution in the UAT environment, find the connection reference, click on it, and select an existing connection from the environment's available connections (or create a new one).
CLI / deployment settings approach: This is where the deployment settings JSON file shines. The ConnectionReferences block in that file maps the logical name of each connection reference to a specific connection ID in the target environment.
To find the connection ID for a connection in the target environment:
# List available connections for a specific connector in the target env
pac connection list \
--environment "https://contoso-uat.crm.dynamics.com" \
--connector "shared_sharepointonline"
The output gives you connection IDs in the format /providers/Microsoft.PowerApps/apis/shared_sharepointonline/connections/abc123. Use that in your settings file.
Warning
Connection references are user-owned by default — the connection is owned by whichever user or service principal created it. In production, always use service accounts or service principals for connection references rather than individual user accounts. If Alice leaves the company, her connections stop working, and every flow and app bound to those connection references fails simultaneously. This is a production incident waiting to happen.
Service Principal Connections
For production-grade deployments, create connections using a service principal (Azure AD app registration) rather than a user account. The mechanics depend on the connector — for Dataverse and Office 365, this is well-supported. For SharePoint, you'll need to configure app-only access in SharePoint Admin.
The key point: document which service principal or service account owns each connection reference in each environment, and include that ownership in your solution's runbook.
Using JSON Environment Variables for Complex Configuration
Text, number, and boolean cover simple cases. JSON environment variables open up sophisticated configuration patterns.
Example: Region-to-Manager Routing Table
Suppose your field services app needs to route work orders to different managers based on region. You could create separate environment variables for each region, or you could store a routing table as a JSON environment variable.
In your Power Automate flow, you'd read this variable and parse it:
// In a flow: Get the environment variable value
// Use the "Get Environment Variable" action or reference via formula
// Then in a subsequent action, parse with:
json(outputs('Get_environment_variable')?['body/value'])
This keeps your routing logic entirely in configuration — no flow edits needed when an organization restructure changes who manages which region.
Tip
Keep JSON environment variable schemas simple and flat where possible. Deeply nested JSON is hard to read, harder to override correctly in deployment settings files, and has no schema validation — a typo in the JSON produces a silent failure. Document the schema in the variable's Description field.
Consuming Environment Variables in Power Apps and Flows
In Power Automate Flows
The primary way to consume an environment variable in a flow is through the Environment Variable action, found in the Microsoft Dataverse connector actions. You reference the variable by schema name. The returned value is always a string — even for numeric and boolean types — so you need to parse accordingly:
// For a number variable:
int(outputs('Get_EnvVar_InvoiceApprovalThreshold')?['body/value'])
// For a boolean variable:
if(outputs('Get_EnvVar_EnableBetaFeatures')?['body/value'] == 'true', true, false)
// For a JSON variable:
json(outputs('Get_EnvVar_RegionRoutingTable')?['body/value'])
Alternatively, within a flow that uses Dataverse connectors, you can directly reference environment variables by schema name in dynamic content — the flow engine resolves them at runtime.
In Canvas Power Apps (Including Custom Pages)
Canvas Power Apps can consume environment variables via the LookUp function against the environmentvariablevalue and environmentvariabledefinition virtual tables:
// Get the current value, falling back to the default
LookUp(
'Environment Variable Values',
'Environment Variable Definition'.'Schema Name' = "contoso_FieldServicesSharePointSiteURL",
Value
)
For custom pages embedded in model-driven apps, this pattern lets the custom page adapt to environment-specific configuration without any hard-coded values in the canvas formula logic.
In Model-Driven App Components
Model-driven forms and views don't directly "read" environment variables in formula columns the way canvas apps do. However, environment variables are commonly used to drive behavior in the Power Automate flows and plug-ins that those forms trigger.
For example, a business rule can't directly reference an environment variable — business rules evaluate on the client and aren't aware of the server-side variable store. But a plug-in registered on the PreOperation event of a table can read environment variables from Dataverse using the IOrganizationService, making them a powerful tool for server-side configuration.
If you're using formula columns — which evaluate server-side using Power Fx — note that as of now, formula columns don't support direct environment variable references either. Keep this boundary in mind as you design.
Hands-On Exercise: Building a Multi-Environment Configuration for a Field Services App
Let's build something real. You'll create a set of environment variables for a field services model-driven app, configure defaults, and simulate a promotion to a second environment.
Setup
You need two environments. Call them FieldServicesDev and FieldServicesUAT. Create a solution called FieldServicesCore with publisher prefix fs in the dev environment.
Step 1: Create the Environment Variables
In FieldServicesCore, create the following environment variables:
After import, run the test flow in the UAT environment. It should use the UAT email addresses and the $5,000 threshold — not the dev defaults.
Step 6: Verify
In the UAT environment, open the FieldServicesCore managed solution and inspect each environment variable. You should see Current value populated with the UAT-specific values, and Default value still showing the dev values from the solution definition.
When you import a managed solution, the environment variable definition shows up in that managed solution. Some makers try to edit the default value there — but you can't (and shouldn't) edit components of a managed solution. You can only set the current value, which is the override layer. If you need to change the default value, change it in the source (unmanaged) solution in dev, then redeploy.
Mistake 2: Forgetting That Flows Suspend on Connection Reference Mismatch
If your flow uses a connection reference that isn't bound to a connection in the target environment, Power Automate suspends the flow after import. This is silent — there's no import error. The flow just sits there, turned off. Always check flow status after a solution import and verify all connection references are bound.
Mistake 3: Setting Current Values in Dev and Including Them in the Export
If you set a current value (not just a default) in your dev environment, and then export the unmanaged solution, that current value can be included in the export. When you import that as a managed solution in UAT, the current value from dev can overwrite any UAT-specific current value you'd previously set.
The fix: don't set current values in your dev environment. Use defaults only in dev. Current values are for target environments.
Warning
This is one of the most common environment variable footguns. Double-check your environment variable definitions in dev before exporting. If you see both a default value and a current value set in dev, clear the current value before exporting.
If an environment variable has no default and no current value in the target environment, it returns null. A flow that does int(null) or concatenates null into a URL will either fail silently (the action uses a blank) or throw a runtime error.
Always add a defensive check in flows that consume environment variables:
// Check that the variable isn't blank before using it
if(empty(variables('EnvVarValue')), 'https://fallback-safe-url.com', variables('EnvVarValue'))
Better yet, include a flow validation step at the start that checks all required environment variables are populated and sends an alert if any are blank.
Mistake 5: Using Environment Variables for Secrets in Text Type
Already covered in the warning above, but worth repeating: Text-type environment variables are not encrypted at rest in any meaningful way. If you need to store an API key, OAuth client secret, or database password, use the Secret type backed by Azure Key Vault. The setup requires a Key Vault and the appropriate Azure permissions, but it's the only production-appropriate approach for sensitive values.
Troubleshooting: Current Value Not Taking Effect
Symptom: You set a current value in the target environment, but the flow or app still seems to use the old value.
Diagnoses:
Flow caching: Power Automate can cache environment variable values for a short period. Wait 5 minutes and retry, or trigger a new run (don't resubmit the cached run).
Wrong schema name: Verify the schema name in your deployment settings file exactly matches the schema name in the environment. Case matters.
Multiple solutions, same variable: If the variable exists in two different solutions in the environment, there may be a layering conflict. Check the solution layer view for the variable definition.
The current value record exists but is blank: A blank current value is not the same as no current value. If a current value record exists with an empty string, that's what gets returned — not the default. Delete the record or populate it correctly.
Troubleshooting: pac solution import Fails with Settings File
If the CLI import fails when you specify a settings file, the most common causes are:
Malformed JSON in the settings file — validate it with a JSON linter before running the import.
The connection ID in the settings file doesn't exist in the target environment — connection IDs are environment-specific.
The schema name in the settings file doesn't match any environment variable in the solution — check for typos.
Run pac solution import --verbose to get detailed error output.
Summary & Next Steps
Environment variables are one of the highest-leverage investments you can make in your Power Platform ALM practice. A solution built around environment variables from the start is genuinely portable — you can promote it through dev, UAT, and production with surgical precision, injecting exactly the right configuration at each stage without touching app logic.
Here's what you've covered:
Architecture: Definitions travel in solutions; current values stay in environments and serve as the override layer.
Data types: Text, Number, Boolean, JSON, Data source, and Secret each have appropriate use cases. JSON is underused and powerful. Secret is non-negotiable for credentials.
Connection references: The companion concept to environment variables for connector credentials. Service accounts, not individuals, should own production connections.
Deployment settings files: The right pattern for automated, repeatable deployments — generate the template with pac solution create-settings, populate per environment, apply with --settings-file on import.
Consuming variables: Flows use the Dataverse connector's environment variable action; canvas apps and custom pages use LookUp against the virtual tables; plug-ins read them via IOrganizationService.
Common failure modes: Suspending flows, null defaults, dev current values contaminating exports, and Text-type secrets.
Where to go from here:
For teams building serious ALM pipelines, the next step is integrating these patterns into Power Platform Pipelines (the native CI/CD tooling in Power Platform) or Azure DevOps with the Power Platform Build Tools extension. Both support deployment settings files natively.
If your solution includes complex security configurations that also need to be environment-aware — specific team assignments, security role configurations — understanding how Dataverse Security: Business Units, Security Roles, and Teams layers with your deployment approach will help you build a complete promotion checklist.
Finally, environment variables are an important part of production hygiene, but they're one piece of a larger puzzle. If your app surfaces sensitive data in forms and views, you'll want to ensure your security model travels correctly too — the lesson on Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data covers what's solution-transportable and what you need to configure per-environment.
Good configuration management is what separates apps that survive their first handoff from apps that require the original developer to be on call forever. Build it right from the start.
