What’s new since preview?

While the most impactful improvements are better reliability, performance, and usability, there’s many new and noteworthy capabilities.

• Disconnect from Git – You can easily disconnect your environment or solution from Git and reconnect to a different source code location or branch.
• Support for existing solutions and large solutions – These critical preview limitations are now addressed. Connect existing solutions in your environment and you won’t be limited by solution size when committing large solutions.
• Public API’s – Now you can interact with Git using Dataverse API’s and build automations to scale the process.
• Support for more object types – most solution components are now supported and we’re incrementally onboarding the remaining legacy components / objects.
• Delete when pulling – when an object is deleted in Git, you now have the option to delete it from your environment or remove from your solution on pull.
• Better user experiences – Git integration is available in Copilot studio (and other maker portals), with improved discoverability, usability, and columns showing who changed what and when.
• Geo availability – Git integration is GA in all public geos and coming soon to sovereign clouds.

Source Control your Canvas Apps

Dataverse Git Integration is the new standard, replacing the experimental Power Apps integration. If you’re still using the old setup, we recommend migrating to the new integration as soon as possible.

With Dataverse Git Integration, you get complete visibility into your source code – no conversions required. You can use pa.yaml files in your repository to manage source control and review changes made in Power Apps Studio, all without the clutter of noisy diffs.

The schema for canvas source code (pa.yaml files) is now published, and no breaking changes are anticipated moving forward.

What’s next?

General availability doesn’t indicate a feature is done – or that it’s without limitations. Rather, Microsoft is confident in the quality for production use. It’s important to evaluate whether current functionality meets your requirements.

Next up is unlocking code-first development. Soon, developer tools will support the new (YAML) format, which is easier to read, understand, and merge. Modern developers can then build and deploy solutions and code from source control with less effort and without prior domain knowledge.

For canvas apps, we will also start to enable (as preview) the capability to edit pa.yaml files directly in your repository.

We’ll be showing code-first demos at Microsoft Build next month, plus many other new and exciting Managed Operations and other capabilities.

Learn more

Setup Git Integration

FAQ

Source Code files for canvas apps

The post Git Integration is Generally Available appeared first on Microsoft Power Platform Blog.

Maker Deployment page

Makers can now view all their deployments in one place, regardless of solution or pipeline. If their deployment began from (or was deployed to) the current environment, they will be able to view the run history status of it. Failed Deployments and Active Deployments are highlighted in a convenient overview, so you don’t have to go looking for them either!

In addition to deployment visibility, we’ve included a Get started section that will evolve over time. For now, it will link to documentation to help a maker begin their journey to healthy application lifecycle management (ALM).

To further improve understanding of what healthy ALM looks like, we’ll soon be adding recommendations, where makers are alerted to resolve any potentially unhealthy ALM-related behavior, such as housing high-use apps outside of a solution.

Admin Deployment page

The Deployment page in the new admin center provides a streamlined experience to help administrators learn about, setup, and operation best-in-class ALM. The initial preview provides a central location to view all deployments in the tenant, approve deployment requests, and troubleshoot failures.

Select a pipelines host from the picker to see all the pipelines and deployment history managed with that host. A dedicated Failed deployments view helps admins quickly identify and troubleshoot failures and trending issues.

Admins can approve or reject deployment requests assigned to them. First setup Delegated deployments with service principals as the recommended way to deploy securely.

It is important that admins review changes in the solution and the sharing request. With the help of Copilot-generated deployment notes visible in the request, this becomes easier, but if you want a more granular look, be sure to set up Source control integration and link the repository to the approval.

Managed Operations

The Deployment pages are an offering of Managed Operations, allowing all who make or administrate to gain further insight into their Application Lifecycle Management to ensure that business solutions are reliable and performant in production. Aside from just deployment pipelines, these maker and admin experiences will evolve over the coming months and include many more Managed Operations intersections to take advantage of. So, stay tuned for more updates and please leave your feedback below!

Learn more

Admin Deployment page

Maker Deployment page

Managed Operations

New Power Platform Admin Center

The post Introducing Maker and Admin Deployment Pages appeared first on Microsoft Power Platform Blog.

It just takes a few seconds to connect your Dataverse environment to Git. You can connect and use Git integration within Power Apps, Microsoft Copilot Studio, Power Automate, and Power Pages. You’ll also need access to an Azure DevOps Git repository.

Rollout is in-progress. Git integration is currently available in public geos outside the US. Your environment must be enabled for early access and accessed at https://make.preview.powerapps.com.

As the team develops, Dataverse tracks everyone’s changes. When ready, commit your changes to a branch in the connected Azure DevOps Git repository. A commit link is provided to view the changes within the repository and compare diffs. You’ll notice solutions and solution objects are now stored in human readable formats in the repo.

Professional developers can work in source control while others work in one or more environments. It’s easy to pull others’ changes into other development environments which are connected to the same source code location. This allows team members to build without others editing in their environment and share changes once they’re ready. Connect multiple development environments using the same repo, branch, and folder. Then, in each environment create or import an unmanaged solution with the same name and publisher.

When committing and pulling changes, conflicts may be detected – meaning someone else made conflicting changes to the same object. You’ll need to choose whether to keep the version that’s in your environment or bring the version from source control into your environment. You can also revert changes in the repository, then pull the prior version into your environment.

When the team is ready to deploy to test or production, you can use Pipelines in Power Platform for the release. Building and deploying using developer tools isn’t available yet for this new format.

We hope you enjoy the preview. There are many current limitations and you shouldn’t use this feature in environments or Git folders where you’re developing production solutions. Please leave your feedback below, in the community forums, on social media, or another outlet of choice. We look forward to hearing what you’d like to see prioritized next.

Learn more

Overview of Power Platform Git integration

Setup Git integration

The post Introducing Git Integration in Power Platform (preview) appeared first on Microsoft Power Platform Blog.

With these updates, we’re excited to announce the general availability of delegated deployments for pipelines in Power Platform!

Additionally, admins can now enable pipelines for multi-geo support, making it easy to centrally administer global deployments within a single management plane.

Build

As makers develop, customizations are automatically saved to their preferred solution (no need to understand or navigate to solutions). This avoids downstream deployment issues, painful debugging steps, and other common mishaps.

 When authoring solution cloud flows, drafts and versioning provides a history for each published version of the flow. Makers can view the version history, restore prior versions, and save draft changes without publishing them live – even if the flow has errors! Then, the flow can be published when they are ready to run the flow. Please leave your drafts and versioning comments and feedback here.

Test

Admins can improve quality by ensuring solution checker runs on every deployment, and configure issue tolerance levels for different environments. Pipelines can be extended to run additional code and security scanning tools, or automated tests by integrating your source control systems. Functional user acceptance testing is also recommended after deployment to test environments.

We recommend starting with pipelines in Power Platform and using extensions if you need to integrate more advanced workloads running in Azure DevOps, GitHub, etc. Similarly, if taking dependencies on test automation, we recommend Test Engine.

Release

Makers are guided to deploy at the right time. For example, when manually exporting and importing solutions or blocked by sharing limits.

Instead, sharing is requested during deployment to target environments, like production, where it’s appropriate to share broadly. Admins simply need to approve the combined deployment and sharing request, and the rest happens automatically. Sharing is rolling out for canvas apps and soon for cloud flows and security roles.

Makers can also update existing environment variables and connection references in pipelines and solution import. Combined, these capabilities protect production assets with least privileged access, reduce admin burden, and train makers to submit all updates via your organization’s change management process. If admins haven’t configured pipelines and governance policies, makers are empowered to create their own pipeline to environments (they must already have access to manually import solutions. Pipelines doesn’t escalate permissions). Admins can apply additional governance controls and manage security within the default host and custom hosts. There’s a new entry point within the solution experience to Manage pipelines and a Security Teams section in the app to manage pipelines access. Note: we currently recommend using a custom pipelines host when more advanced control is desired.

 

Why pipelines vs manual export/import? Unlike manual export/import, pipelines stores backups for every version of every solution deployed, and admin accessible audit logs describing who, what, when, where, and why (AI provided). Pipelines deployments enjoy higher success rates by pre-validating solutions against target environments and sequencing multiple deployments to avoid conflicts. 

 

Solution simplification remains an ongoing effort. Recent improvements include streamlined dependency management and automatic conversion of unmanaged to managed solution objects (see moving from unmanaged to managed solutions).

 

What if breaking changes are inadvertently deployed? Now makers and admins can now re-deploy prior solution versions using pipelines or developer tooling.

 

Documentation

• ALM Guide
• Pipelines in Power Platform
• Managed environments
• Power Platform Developer tools
   

The post April 2024 ALM blog: What’s new and what it means for you appeared first on Microsoft Power Platform Blog.

​Delegated deployments run pipelines as service principals, or as the pipeline owner (including service accounts).​ This ensures developers of any skill level can request deployments without needing elevated (or any) permissions in target environments. For security reasons, approvals are required – whether automated or manual. This is simple and highly capable with Power Automate Approvals and Copilot powered deployment notes providing pertinent information about the deployment request.​

Delegated deployments has been the top requested pipelines feature since we launched pipelines preview last December. But it’s not about blocking developers, or inhibiting the ROI realized from enabling citizen development with the Power Platform. Rather, it’s about empowering citizen development at scale without sacrificing security or auditability.

We’ve also introduced another pipelines extension with this update. Now you can run custom validation logic before solutions are exported from development environments. Combined, pipelines now offers three gated extensions, opening the in-product deployment capabilities to a wide range of use cases. Similarly, pipelines can be customized with low-code, no-code, and/or pro-code.

We’d love your feedback and look forward to more customers empowering citizen developers while also protecting their production assets.

Learn more

​

The post Announcing pipelines delegated deployments (SPN) appeared first on Microsoft Power Platform Blog.

It only takes a few minutes to configure pipelines and share with makers. Pipelines are then run directly within development environments or PAC CLI. An intuitive in-product experience guides the deployment process and educates citizen developers about healthy ALM practices. This is easy to understand with automatic safeguards applied and complexities abstracted by the system. For example, connections, environment variables, and deployment pre-validations are built into the experience, ensuring citizen devs and the applications deployed are more successful.

You might have noticed we’re announcing GA sooner than initially anticipated. Why is that?

Customer adoption and feedback during preview have been overwhelmingly positive with many customers expressing desire to use pipelines in production (which is typically inadvisable for preview features). We’ve shipped many updates during the preview to improve overall quality, reliability, and ensure backward compatibility for upcoming releases. Numerous signals we monitor provide high confidence in Microsoft’s ability to support your production workloads at any scale.

Rest assured; there’s no shortage of new pipelines features and experience improvements in the works. Our roadmap remains intact, and we’re committed to supporting larger scale projects that often necessitate more advanced ALM functionality. I’d like to share what the team is currently developing and will be made available shortly. This is not an exhaustive list of what’s coming. The below GIFs were recorded from actual working demos and edited for length.

Schedule deployments (coming soon)

Often, customers wish to deploy updates during non-business hours. It minimizes risks of impacting end users during their workday and resulting business impact. Automation ensures you can ship smaller, more frequent, updates on a scheduled basis. It also avoids the team working weekends to attend deployments. In fact, at Microsoft we use similar techniques to release Power Platform updates and soon customers can achieve the same.

But that’s not the only reason we needed scheduling functionality. The ability to capture a deployment request without immediately deploying is a prerequisite for much more.

Pipelines extensibility (coming soon)

Soon you’ll be able to run custom logic both before and after a deployment executes. Using Power Automate cloud flows, the possibilities are rather endless. There are over 900 built-in connectors as well as the ability to develop custom connectors.

Configuring a pre-step condition on a deployment stage ensures the deployment request to the target environment is pending until the deployment is approved. The system then carries out the automated deployment. Similarly, you could incorporate automation running within other systems. For example, committing solutions to a source code repository or running automated tests. With Power Platform handling the heavy lifting, these hybrid approaches enable advanced functionality at a fraction of the setup and maintenance costs when compared to running DevOps tools standalone. Perhaps most importantly, the maker friendly in-product experience doesn’t expose background complexities.

Configuring a post-step condition on a deployment stage can also be leveraged for running advanced post-deployment logic, or simple automations such as notifying a maker when their deployment succeeds.

Delegated deployments (coming soon)

What about preventing makers from customizing directly in production? Today, some customers use service principals within Azure DevOps and GitHub to deploy solutions. This way, only the service principal is required to have customization permissions in prod (required to import solutions). Not makers. However, it can become quite cumbersome to setup and manage. Soon, these use cases will be supported within pipelines in Power Platform. Note this will become available after scheduling and extensibility.

Managed environments

Pipelines requires access to one or more Managed Environments. While the date for pipelines GA has changed, the timeline for enforcing use of Managed Environments in pipelines hasn’t. We intend to add these enforcements in the second half of 2023 to help admins stay compliant. Developer environments can now be enabled as Managed Environments and used in pipelines for development and QA through the Power Apps Developer Plan license. It’s a good time to start planning your environment strategy if you haven’t done so already.

Learn more about pipelines

• Pipelines overview Microsoft docs
• Set up pipelines. Microsoft docs
• Run a pipeline. Microsoft docs

Videos:

• New! How to do ALM with Power Platform. Video comparing what’s available in Azure DevOps, GitHub, and pipelines in Power Platform with Casey Burke and Kartik Kanakasabesan
• Microsoft Mechanics. Video on Managed environments and pipelines with host Jeremy Chapman and Power Apps GPM Evan Lew
• Power CAT Live. Video on pipelines with host Phil Topness, and PM’s Casey Burke and Kartik Kanakasabesan

We’re grateful for the overwhelming support and customer feedback received during the preview. Please do keep it coming! You can comment below and in the Power Apps community.

The post Pipelines in Power Platform is Generally Available (GA) appeared first on Microsoft Power Platform Blog.

When makers export and import solutions from development environments to production environments manually, IT loses visibility and control over apps. Some customers use pro-dev and IT-centric tools, like Microsoft Azure DevOps and GitHub Actions to implement an automated ALM process in their organization. While powerful, these tools are not citizen-developer friendly and often rely on a DevOps team to drive implementation and oversee the process. Pipelines aims to bridge this gap in a manner that’s much simpler, faster, and cost-effective to setup and maintain.

Pipelines can be setup and run entirely within Power Platform – with governance, visibility, and safeguards automatically built in so that your business solutions can come to market faster with less effort and higher quality. The system handles all the heavy lifting and ongoing maintenance so you don’t have to.

1. Admins easily configure automated deployment pipelines in minutes rather than days or weeks. Then manage access and view all deployment activity across your organization within the same location. Start simple (yet healthy) with the option to later extend pipelines as your business needs and product capabilities evolve.
2. Makers have an intuitive user experience for deploying their solutions in just a few clicks – directly within the environment they’re already working in. Before initiating the deployment, connections are automatically setup or mapped in the target environment and new environment variable values can be provided. This ensures everything is properly connected when deployed.
3. Professional developers can (optionally) retrieve pipeline information as well as run pipelines using their preferred tools such as the Power Platform command line interface (CLI). Underlying tasks required previously to accomplish the same outcome are now handled by pipelines. Developers just need to tell the system what they want to accomplish instead of needing to manage how it’s accomplished.

Getting started

It’s never been easier to setup automated deployment pipelines across your Power Platform environments. Simply create the environments you’ll use for ALM, install the Power Platform pipelines application in one environment (which will host all pipeline configuration and run data spanning multiple other environments your pipelines interact with). Next, create one or more pipelines and link the development and target environments. That’s it! Now you can run them directly within any development environment(s) associated with the pipeline.

You can then see reports for all deployment activity across your organization, access error and audit logs, retrieve backups of all solution files, and much more.

Note that pipelines is in preview and may not be available in your region yet. Pipelines is a feature of Managed Environments and you will need access to one or more Managed Environments to use these capabilities (although this requirement won’t be enforced until Pipelines is generally available).

Feedback and what’s next?

This is the beginning of a new journey for Power Platform ALM. We don’t expect it to address every use case for every customer immediately. We’ll add improvements with each iteration and your feedback is incredibly valuable in helping prioritize what’s most critical to tackle next! Please leave your feedback below and in the Power Apps community.

We’re really excited about many other capabilities already in the works. Soon you’ll be able to better custom tailor pipelines to the needs of your organization with more streamlined interfaces, deployments with approvals, ability to add your own custom logic and extensions, and ensuring pipelines within Power Platform is a welcomed addition to ALM processes being orchestrated using other software systems and tools. Note that pipelines do not intend to compete with powerful DevOps systems such as Azure DevOps and GitHub. Rather, pipelines intends to serve as the baseline for Power Platform ALM – with Power Platform handling its’ own sophistication internally so that you don’t need to externally. And with DevOps and COE tools being the mechanics to extend in-product ALM capabilities to accommodate your more advanced workloads.

Thank you for reading. On a personal note, I want to thank the many teams and leaders that came together to deliver these capabilities. What may appear simple on the outside, has a great deal of sophistication on the inside. I’m grateful having the opportunity to work with such a talented team and passionate group of customers and partners. We’re not done and look forward to your feedback as well as what comes next. From us to you, have a wonderful holiday season!

Learn more about pipelines

• Microsoft Mechanics. Video on Managed environments and pipelines with host Jeremy Chapman and Power Apps GPM Evan Lew
• Power CAT Live. Video on pipelines with host Phil Topness, and PM’s Casey Burke and Kartik Kanakasabesan
• Pipelines overview Microsoft docs
• Set up pipelines. Microsoft docs
• Run a pipeline. Microsoft docs

The post Automate deployments with pipelines in Power Platform, now in preview appeared first on Microsoft Power Platform Blog.

Goals and new features for GA

Modern commanding has many improvements since the preview was announced last year. We sincerely appreciate the overwhelming amount of support and feedback from the Power Platform community and the close partnership with Scott Durrow (Microsoft MVP and Ribbon Workbench creator). This has helped shape the below goals and GA features.

Makers love the experience

A large number of usability and maker productivity improvements have resulted in a simpler and streamlined maker experience. A few highlights include the addition of copy + paste, optimized navigation & layout, drag and drop within command designer, performance improvements, and deferring creation of command component libraries.

Do more with Power Fx

Various new functions are now available to better support common command use cases. Defining visibility, actions, and interacting with custom pages is now much more powerful. For example, control command visibility using RecordInfo() and DataSourceInfo(), and work with unsaved data (aka the buffer) using Self.Selected.Unsaved.

No cliffs

Many parity gaps with classic Ribbon commands have been closed (+ a ton of new goodness not previously possible). For example, now you can create dropdowns, split buttons, and groups as well as specify different scopes – which determine whether a command is published to a single app, to a table and all apps using it, or even globally to all apps and all tables.

These new scopes prevent duplicating effort for commands that need to be present in multiple apps. As an added benefit, when citizen developers modify or hide broader scoped commands, their changes are automatically isolated within their app and other apps remain unaffected.

Rock solid reliability and ALM

The most important improvements are not typically visible. We’ve made significant investments into strengthening the modern commanding infrastructure, fixing issues, improving performance and reliability, and ensuring application lifecycle management is handled consistently.

What’s next?

GA is a milestone, not an end state. There’s much more we’d like to do and while I can’t share everything just yet, here’s a few improvements coming soon:

• Editing Microsoft first party (OOB) commands using modern command designer. We realize this limitation is especially painful and have been working diligently to solve this complex problem reliably.
  • Classic OOB commands will be incrementally migrated to the modern commanding infrastructure.
  • Migrated commands will be fully supported in command designer.
  • Migration will not impact existing customer customization or the ability to continue using classic capabilities. We’ll later provide an easy button to migrate your own classic commands.
• Support for classic enable rules, display rules, and custom rules.
• Supporting additional Power Fx functions and improving the publishing experience.
• Addressing other known limitations.

Learn more

Check out the modern commanding documentation as well as the recent Power CAT Live interview with Phil Topness, Prabhat Pandey, and Casey Burke.

The post Announcing the general availability of Power Apps modern commanding appeared first on Microsoft Power Platform Blog.

These new capabilities are a complete re-imagination of commanding (formerly known as the “Ribbon”) for model-driven apps. It’s built on a new,  modern infrastructure that’s conducive to both model-driven and canvas app technologies and will scale into the future.

Key improvements

• Enhances custom pages (or the convergence of canvas and model-driven apps)
  • Open a custom page as a dialog
    • You can also trigger cloud flows from a button on the custom page
• Power Fx support for visibility and action logic
  • Or use JavaScript for more advanced logic (you may also continue using existing JavaScript as-is)
• Command designer simplifies customization – whether low-code or pro-code
• Better ALM support along with standardized localization and presence in the solution interface
• Better app level control – commands are applied to individual apps
• Simple, flat data model
• Classic commands remain supported, Apps can run both classic + modern commands side by side
  • No forced migration
  • Arrange modern commands amongst existing classic commands

Please note these are preview features and the intent is to provide early access and collect feedback while we work to incorporate additional functionality. This new infrastructure does not yet support many things you may want to do – nor does it have full parity with classic commanding capabilities. We invite you to join us in this journey that is only just beginning. 
Please also note these features may not be available in your region yet.

Special thanks to Scott Durrow, MVP and creator of the Ribbon Workbench, for the close partnership in the re-imagination of commanding.

Leave your feedback below or in the community for what you like or dislike as well as what features are missing for your use cases.

Learn more

Command designer overview
Custom page overview

The post Announcing command designer with Power Fx (preview) appeared first on Microsoft Power Platform Blog.

Why data source environment variables?

Environment variables have been a powerful tool for a variety of ALM scenarios as they allow you to externalize input parameters from the components that use them. They’re now much simpler to work with and can store parameters required to connect to data.  This allows you to change the data sources (as well as other types of parameters) when migrating solutions to other environments.

Build

• Environment variables are automatically created to store data source parameters when connecting to data within canvas apps. *Limited set of connectors. Refer to docs for the latest information
• Reuse the same environment variables across canvas apps, flows, and other components
• Natively insert any type of environment variable in triggers and actions within cloud flows. *Limited set of connectors for trigger support
• Doesn’t require querying environment variables via Dataverse connector or require premium licenses like before

Deploy & Automate

• Provide new values when importing solutions in a user friendly UI
• Various new API’s and API enhancements dramatically simplify programmatic interactions. We use the same API’s internally and now customers can use them! *API’s are live. Docs are in the process of being published
• Change values in build pipelines and source control
• New build tasks will be available soon for working with connection references and environment variables
• New ALM Accelerator will be available soon to package the use of these assets & allow customers to quickly get started with automated ALM

Govern

• Gives admins more control and visibility over data sources used in apps and flows
• Admins can retire and replace a production data source without modification to the apps and flows

Let’s use a simple example:

• I use different Power Platform environments for development, QA, and Production
• In the development environment I build a canvas app and flow that connect to a development SharePoint site and list
  • Similarly, I have different SharePoint sites and lists for dev, QA, prod
• When I migrate the solution containing the apps and flows to QA and Production environments they must connect to the corresponding QA and Production SharePoint lists

Step 1: Create my solution and canvas app

1. Login to Power Apps or Power Automate
2. Create a new solution
3. Create a canvas app from the solution
4. In the canvas app designer enable the setting to Automatically create environment variables when adding data sources
   1. This step is optional if following the approach in 7a
5. 
6. Add a data source for SharePoint and select a site, then one or more lists as you ordinarily would.
7. Now you’ll see a confirmation screen to notify you that environment variables will be created
   1. Note: data source environment variables can also be created within the solution interface. You can select pre-existing environment variables when adding a data source to your app by clicking the “Advanced” tab
8. When you save the data source your app is now connected to SharePoint via two related environment variables. One to hold the site URL and one to hold the list ID (dataset and table parameters)

Step 2: Create a cloud flow

1. Add a button to your app
2. For the action select Power Automate, then Create a new flow
3. Set the trigger
4. Choose an action for SharePoint. I’ll use Create item for this example.
5. In the Site address parameter, scroll down and click Enter custom value
6. Under Dynamic content you’ll see a list of environment variables to choose from
7. Select the appropriate site environment variable created when building the canvas app in step 1
8. Do the same for List name, then save the flow
9. Your flow is now connected to the same SharePoint site and list and using the same environment variables as your app

Note: Some experience improvements are rolling out and some are still in-development. For example, the “Parameters” label will soon be “Environment variables” and the list will have better filtering based on the parameter type. 

Step 3: Migrate your solution to another environment

If you want to provide new environment variable values when importing to other environments, it’s important to remove the values from your solution before it’s exported. You do not need to delete them from the environment, however. This way everything will remain connected in the development environment. 

1. Select the SharePoint site environment variable in your solution. In the edit panel, select the ellipsis by Current site, then Remove from this solution
2. Do the same for the SharePoint list environment variable
3. Export the solution as managed
4. Switch to a different environment, then import the solution
5. You’ll be prompted to select a SharePoint connection (for the connection reference), then can proceed to provide new values for the environment variables
6. Import the solution and everything will be connected to the new SharePoint site and list. No need to modify or turn on anything!

Step 4: Manage

It’s important to ensure users of the application have appropriate access. In addition to sharing the apps and flows, they’ll need an appropriate security role granting access to canvas apps, processes, and environment variables in Dataverse.

If you need to change the data sources being used in a production environment, you may edit the values of the environment variables or update them via managed solution upgrade. Any apps and flows using the environment variables will start using the new values.

More information

For more information please refer to the docs.

In case you’re unfamiliar with importing solutions, connection references, and environment variables I suggest reading this blog post to gain a base understanding. 
We’d love to hear your feedback. Please comment below or visit the Power Apps community site.

The post Announcing data source environment variables appeared first on Microsoft Power Platform Blog.