A developer is building a Copilot Studio agent that calls an external API. The API base URL differs between development (https://api-dev.contoso.com) and production (https://api.contoso.com). The developer wants to manage this difference without modifying the agent's topics or flows when promoting between environments. What is the recommended approach?
Select an answer to reveal the explanation.
Short Explanation
Environment variables are the config knob that lets you promote a solution without touching code. Set the value per environment at import time, and the flows and connectors pick up the right URL automatically.
Full Explanation
Power Platform environment variables are designed exactly for this pattern — storing configuration values that differ between environments within the same solution artifact.
The correct approach is to create a Power Platform environment variable of type String to store the API base URL, reference it in the flow and connector configuration, and set the correct value per environment during solution import. The String-type environment variable named something like 'ApiBaseUrl' is added to the solution. Inside the Power Automate flow or custom connector base URL, the environment variable is referenced instead of a hard-coded URL. When the solution is imported into production, the import wizard prompts the administrator to set the production value. No modifications to the solution components are needed.
The hard-coded production URL in the topic HTTP action with a topic-level variable override during development testing is incorrect. It is fragile, error-prone, and requires manual intervention on every deployment. It also means the solution itself contains environment-specific values.
The two separate custom connectors — one for dev and one for production — with swapping which connector the topic uses before each promotion is incorrect. Maintaining two custom connectors doubles the maintenance burden and the promotion process. Connector definitions would still need to be swapped or managed separately, and this approach doesn't scale to more environments.
The SharePoint list storing environment-specific URLs and having the agent query SharePoint at runtime to determine which URL to use is incorrect. Querying SharePoint at runtime to get configuration values adds latency to every agent interaction, creates a dependency on SharePoint availability, and adds unnecessary complexity. Environment variables are the right tool for this job.