I recently enjoyed being involved in an internal Power Platform modernization hackathon. I want to share my experience to provide valuable insights and/or ideas to help others decide if they will participate in or host a hackathon themselves.

What is a Hackathon?

A hackathon is typically a single sprint event where a group of motivated technical folks collaborates intensely to implement and demonstrate the solution to a problem use case chosen by each team. It is a rapid development effort where the solutions are designed and implemented towards the overall goals of the hackathon event. Besides valuable business/account benefits, hackathons are known to be great opportunities for hands-on learning and upgrading technical skillsets.

AIS Internal Hackathon

AIS held an internal Power Platform hackathon in the summer of 2021. One such stirring event helped a few motivated AIS team members to learn and upgrade their Power Platform skills while applying those to solve practical problem scenarios at one of our major clients. The event focused on relevant use cases that can use the many features of Power Platform to solve real-time gaps and/or problems across our client enterprise. There were six teams of 4-6 team members each. Each team had at least one Power Platform developer and one person familiar with the client’s business domain. A set of senior Power Platform SMEs acted as advisors for the event.

The Case and Team

I’ve had the opportunity to propose two of the six use cases selected by a team for implementation. My team focused on a crucial financial reconciliation process which proved to be a spot-on candidate for Power Platform modernization. The existing production system was a dusty Windows Forms application created at lightning speed by AIS to help our client avoid renewing a costly COTS product. Power Rippers’ hackathon team consisted of a Power Platform developer and three .NET developers with no Power Platform experience. Two of the team members had domain experience specific to the client we focused on. We’ve had an excellent experience working intensely on the effort as a mini-project. We leveraged Microsoft Teams for all collaboration, including recorded meet-ups, shared OneNote’s, and linked a OneDrive library app to the chat space.

Power Platform and its Wide Range

We learned, utilized, and integrated a wide range of Power Platform components like Model-Driven App, Dataverse, Dataflow, Power BI, paginated reports, data alerts, Power Automate, and OneDrive. Using these technologies, we modernized the existing business processes. In addition, we added a few Power Platform-backed enhancements to demonstrate how the platform can empower business users further.

Component Level Interaction


We had our share of hiccups in the project, which proved to be a significant part of the learning experience. Our team secured 2nd place, which came with a monetary reward!

From a business standpoint, it did not stop there. We made our application into a proof concept. We presented to the application leadership as a possible solution to replace the existing application, with benefits such as the following:

  • An application that is easier to maintain
  • More functionality than the original application
  • Decreased level of effort and costs for continued enhancements
  • The ability for the client to configure many aspects of the application through model-driven application
  • Moving the application to a platform where the functionality could be maintained, and enhancements could be done by the client themselves with limited training.

From a personal standpoint, it ticked a few checkboxes for my growth, like becoming familiar with PowerApps and Power BI to an intermediary level vs. a lesser-than-a-novice before this. It also allowed me to present my first Lightning Talk, a short presentation to pass on what I learned to others within my company.

The Transformation Saga

This excellent transformation story of a third-party product rewrites into a Power Platform opportunity that materialized to reality due to the hackathon.

The Transformation Story of Power Platform

Why AIS?

This effort is a testament to the technical learning appetite of AIS folks, how we as a company strive to make things beneficial and better for our clients. It also demonstrated how internal activities like hackathons, level-up sessions, lightning talks, etc. help participants achieve personal goals and work together to share their skills and knowledge.

Hello, Power Platform Devs! In this blog post, I’d like to highlight my learning experience with the AIS HUB Team that you can take advantage of to get started with Power Platform fundamentals.

What is the HUB Team?

The AIS Cloud Acceleration Hub (HUB) is a dedicated team of AIS consultants organized to help our project teams deliver successful cloud solutions. The HUB team consolidates knowledge and experience to provide rapid research and guidance services for AIS delivery teams at no additional cost to our customers.

What is Power Platform?

Power Platform is a business application platform that allows users to create and deploy applications with the help of its four components.

The four components of Power Platform

Components of Power Platform

Power Apps

Power Apps provides a rapid low code development environment for building custom apps for business needs.

Key features:

  • Low/no-code platform for building apps
  • Work with data where it lives.
  • Add artificial intelligence to your app with no code

Types of Power Apps:

  • Canvas Apps – Canvas apps are a great option when you want to build an app from a blank canvas. You start by choosing the screen size: tablet or mobile
  • Model-Driven Apps – Model-driven app design is a component-focused approach to app development.
  • Portals – Portals bring the power of no-code solutions to building external-facing websites. You can build an anonymous or authenticated website through the Power Apps interface that allows users to interact with data held in Dataverse.

AIS was recognized as a Finalist for the Microsoft 2021 Power Apps and Power Automate Partner of the Year Award.

Power Automate

Power Automate lets users create automated workflows between applications and services. It helps automate repetitive business processes such as communication, data collections, and decision approvals.

Key features:

  • Automated workflows between applications and services
  • Process Automation
  • Provides Saved Templates

Types of flows:

  • Event-Driven Flows – These are flows that you build with a trigger and then one or more actions. There are many triggers and actions available, thanks to the existing connectors.
  • Business Process Flows – These flows are built to augment the experience when using Model-driven apps and the Dataverse. Use these to create a guided experience in your Model-driven apps.
  • Desktop Flows – These robotic process automation (RPA) flows allow you to record yourself performing actions on your desktop or within a web browser.

Beyond simple workflows, Power Automate can send reminders on past due tasks, move business data between systems on a schedule, talk to more than 275 data sources or any publicly available API.

AIS held an internal hackathon for Microsoft Power Platform to expose our team to the platform, concepts, approaches through hands-on experience.

Power BI

Power BI (Business Intelligence) is a business analytics service that delivers insights for analyzing data. It can share those insights through data visualizations which make up reports and dashboards to enable fast, informed decisions.

Key features:

  • Business analytics service that delivers insights for analyzing data. It helps with the following:
    • Connect to Data
    • Transform Data
    • Visualize Data

Building Blocks of Power BI:

  • Datasets
  • Reports
  • Dashboards

Power BI lets you easily connect to your data sources, clean, and model your data without affecting the underlying source, visualize (or discover) what’s important, and share that with anyone or everyone you want.

Power Virtual Agents

Power Virtual Agents enables anyone to create powerful chatbots using a guided, no-code graphical interface without the need for data scientists or developers.

Key features:

  • Create chatbots using a guided, no-code graphical interface

Minimizes the IT effort required to deploy and maintain a custom solution. We can perform the following tasks:

  • Create a chatbot
  • Test a chatbot
  • Publish a chatbot
  • Analyze a chatbot

Hands-on Links:


Power Platform features offer several features. Some of my favorites on Power Platform are AI Builder, which allows users and developers to add AI capabilities to the workflows. Microsoft Dataverse lets users securely store and manage data from multiple sources, and Connectors enable you to connect to apps and data, and devices in the cloud. We will discuss these in detail in the next blog. Stay tuned!



One of the challenges I had when learning Dynamics 365 / Power Platform development was how to add custom functionality to the User Interface. The .NET developer in me was frustrated when I wanted to add a button to the page that triggered some server-side code. Eventually, I learned a pattern of adding HTML / JavaScript resources to the page that would create an Annotation (Note). A plugin would intercept the Annotation and get the Regarding object. This would allow me to trigger server-side code from the User Interface, but it was not as graceful as I would have liked. A colleague of mine, Patrick O’Gorman, told me about Power Apps Component Framework (PCF) controls for some time, and I recently decided to start experimenting with them. In this blog post, I will illustrate how I could use a PCF control to trigger a flow in Power Automate.

Creating the PCF Control

Before creating the control, I recommend reviewing both the Microsoft Learning Paths for Power Platform Component Framework and Patrick O’Gorman’s PCF Demo.

I begin by creating a folder to house the project and then follow these steps:

  • Open Visual Studio (VS) Code
  • In VS Code, Open the folder that was created for the project
  • Click View and then TerminalIn the terminal window, I do the following:
  • Initialize the project: pac pcf init –namespace PCFControls –name PCFFlowTriggerDemo –template field
  • Install TypeScript: npm install typescript
  • Build the project: npm run build
  • Run the project: npm start

When I run the project, the PCF Control Sandbox opens. It is empty at this point, but not for long.

Empty PCF Control

I close the Sandbox window and use CTRL+C to terminate the Sandbox in the terminal window.

Creating the Power Automate Flow

For this project, I will set the control to the side for now and create the flow because I will want the endpoint created to use in control. For this example, I will create a simple workflow that receives a Contact Id from the PCF Control and then emails the Contact. I realize there are better methods for emailing a client within the Model Driven App, but this is just an example. I create this flow by following these steps:

Configure the Trigger

Login to Power Automate

Create New Flow and choose Instant cloud flow

Create New Flow and choose instant cloud flow

Enter the name of the flow and choose When an HTTP request is received (Request) for the trigger.

Build and instant cloud flow

When the flow opens, expand the trigger and select Use sample payload to generate schema.
Use the following JavaScript Object Notation (JSON)
{ “contact” : { “contactid”: “00000000-0000-0000-0000-000000000000”} }

Enter or paste a sample JSON payload

Click Done and the schema generates:

When HTTP request is received

Check the Origin

Next, I verify that the request’s origin is from my Power App. This prevents someone from using PostMan, Fiddler, etc. to build a request and hit the endpoint maliciously.

Click New Step > Control > Condition
Click left-hand Choose a value > Expression and enter the following:

Choose a Value and Expression

Click left-hand Choose a value and enter the root URL for Power App (ex. https://orgc76a7275.crm.dynamics.com)

Email the Contact

Inside of the Yes condition, click Add an action > choose Microsoft Dataverse as the connector and then Get a row by ID.
Select Contact as the table and select the contacted from Dynamic content in the Row ID field.

Select contact as the table

Inside the Yes condition, click Add an action > type Outlook, select Office 365 Outlook as the connector type, and then Send an email.
Click To > Add dynamic content and then select Email.

Send an email

I fill in other required fields to send a test email.

Send a test email

Click Save

Get the POST URL

Now that the flow is complete and we have saved it, the POST URL is made available. I scroll back up to the top of the flow and expand the trigger; I copy the URL and save it later.


Triggering the Flow from the Control

Now that I have the PCF control project in place and the flow complete, I can finish the control. I return to VS Code, open the index.ts, and perform the following steps:
I want to add a variable for the current context and the container that I will be using to build our control. Add the following lines just above the constructor.

               private _context: ComponentFramework.Context<IInputs>;
              private _container: HTMLDivElement;

Triggering the Flow from the Control

Next, I need to create an HTML Div element, add a button, and add an event listener for the click event. Locate the init method and replace the code inside with the following lines:

                              this._context = context;
                             this._container = document.createElement("div");
                             let button: HTMLButtonElement = document.createElement("button");
                             button.id = "cf6e3bc1-1cc1-4404-9171-9b7c981f97f6"
                            button.innerHTML = "Email Contact";
               button.addEventListener("click", this.emailContactOnClickHandler.bind(this));

Triggering flow from control

Finally, I need to add the click event handler. This code gets the Id of the current Id of the record, builds the JSON payload that I used earlier, posts it to the URL from our flow, and disables the button (to prevent spamming it). Below the destroy method but inside the class, add the following method:

	private emailContactOnClickHandler(event: Event): void {
		var context = this._context;

		var contactId = (<any>context).page.entityId;
		var contactPayload = '{ "contact" : { "contactid": "' + contactId + '"} }';

		var req = new XMLHttpRequest();
		var url = "[URL FROM FLOW]";
		req.open("POST", url, true);
		req.setRequestHeader('Content-Type', 'application/json');

		let button = document.getElementById("cf6e3bc1-1cc1-4404-9171-9b7c981f97f6")
		if (button) {
			(button as HTMLButtonElement).innerHTML = "Email Sent...";
			(button as HTMLButtonElement).disabled = true;

Destroy Method

You may have noticed that I am using a GUID for the button; there is nothing special about this GUID, and any can be used. I just needed a unique Id for the button control to retrieve it later. I also left out the URL from the flow; this should be the value created when the flow was saved. Now I can build and run the project:

  • Build the project: npm run build
  • Run the project: npm start

When I run the project, the PCF Control Sandbox opens, and we can see our button element now.

Power Apps Test Environment

I close the Sandbox window and use CTRL+C to terminate the Sandbox in the terminal window.

Deploying the PCF Control

Now I am ready to deploy the control of my Model Driven App; in this case, I am using a Dynamics 365 Sales Trial. I deploy the new control by doing the following:

Publishing the Solution

  • In the terminal window, I authenticate with my App: pac auth create –url https://orgc76a7275.crm.dynamics.com
  • I build the project: npm run build
  • When the login window pops up, I enter my credentials
  • I deploy the solution: pac pcf push –publisher-prefix ais

Adding the Control to the UI

I click on the gear, select Advanced Settings.

Advanced Settings

I click the drop-down next to Settings and then click Customizations and then Customize the System.

Customize the System

Note: Normally, I would use a custom solution instead of Customize the System. When I use Customize the System, I am editing the default solution that I am not concerned about for this example.

In the Solution window that opens, I expand Entities, locate and expand Contact, select Fields, and then click New.

Contact Fields

For the Display Name, I use “PCF Email Contact” and change Searchable equal to false; this will prevent the field from appearing as a search as an option. This field will serve as a placeholder for my control. I leave everything else as-is and click Save and Close.

PCF Email Contract

In the Solution, select Forms and then open the form. In my case, the entity is configured to use the Sales Insights by default, so I will edit it.

Sales Insights

In the form window that opens, I locate my newly created field and drag it right below the Email field.

New Field with Email

I double-click on the field, uncheck the Display label on the form, and then select the Controls tab.

Display label on the form

In the window that pops up, I can see my new control.

Add PCF Trigger Control

I select it and click Add.
In the Field Properties window, I tick the options Web, Phone, Tablet and click Ok.

Field Properties

In the form window, I click Save and Close.
In the Solutions window, I click Publish All Customizations.

PCF Control in Action

Now that I have the PCF control deployed and the flow waiting for a POST request, I am ready to test. I have created a Contact record with my email address, and now when I edit it, I see the Email Contact button.

PCF Control in Action

When I click it, it is disabled and changes to Email Sent.

Disable and Send Email

When I navigate to Power Automate I see that my flow has been completed successfully.

Successful flow completed

Finally, I check my email and it is correct.

Check email


As you can see, wiring up a control to your Power App with server-side logic is easy with Power Platform. Power Automate provides you with fantastic low / no-code solutions, and the Power Apps Component Framework makes it easy to design, publish and connect controls to your user interface.

Project Background

From August 2020 to this February, I worked as a Business Analyst (BA) on a project team to help a major insurance company modernize thousands of InfoPath forms into the Microsoft Power Platform. Our client needed to retain critical business functionality and workflows of these forms before Microsoft ends their extended InfoPath support in July 2026. Our efforts included modernizing the InfoPath forms by using Power Apps canvas apps, Power Automate, and some Power BI.

It was a great experience working on this project. First of all, I got to work with a project team with members specializing in different technical areas who were motivated to mentor and learn from each other. I learned about the Power Platform, Power Platform accessibility, Modern SharePoint lists, and some QA testing basics.

At the same time, as a BA with an extensive background in user experience (UX) research, I contributed to the project’s success by sharing and implementing UX best practices and helping improve the overall usability of our applications. Throughout the project, I had opportunities to:

  • Lead project discovery that followed a user-centered design process involved multiple activities and steps within our internal AIS team and with our client stakeholders.
  • Prototype the new solution first in Axure and later on directly in the Power Platform – the low-code/no-code, connected, and secure platform, which empowers citizen developers like me to solve business problems.
  • Work with our team to improve overall form design for better usability, including improving form labels, instructions, and controls.

I describe my overall project experience in a two-part blog post:

  • Part 1 (this post) focuses on how we followed a user-centered design process to conduct InfoPath form discovery.
  • Part 2 compares prototyping in Axure and Power Apps and illustrates how we improved form design from InfoPath to Power Apps.

User-Centered Design/Discovery Process

Our project included ten members: 1 Project Manager, 1 Power Platform Solution Architect, 3 Power Platform Developers, 2 Accessibility Specialists, 1 UX Architect, 1 QA Test Engineer, and me as the BA. The Power Platform Solution Architect, UX Architect, and I formed the discovery team, with constant support and participation from our Project Manager.

Our project followed an Agile process with two-week sprints, and our discovery team of three worked on the target InfoPath forms a sprint ahead of the rest of the team members. When our Developers and Test Engineer were ready to start developing and testing the new app, we had already completed the needed discovery. We received the client’s approval on the app requirements. Figure 1 below depicts our simplified discovery process.

Design Discovery for Agile Process

Detailed Discovery Steps

In reality, multiple activities and meetings could occur in each step, and below are more details of how we conducted discovery.

  1. While familiarizing ourselves with the target InfoPath form(s), our discovery team focused on forms themselves and reviewed relevant
    • SharePoint site(s), different SharePoint list views, and workflows.
    • It was helpful for us to understand the form context, which was necessary for our conversations with stakeholders.
    • I created a Stakeholder Interview Guide Template at the beginning of the Project and constantly updated the Template with tailored questions.
    • We might hold an internal meeting about the initial findings before we met with client stakeholders.
  2. Regarding our initial meeting with key stakeholders/form owners:
    • To ensure their attendance, I always tried to schedule meetings at least one week in advance.
    • During the meeting, I followed the Interview Guide, focusing on their existing use of the InfoPath forms and workflows, what worked well, what pain points they experienced, and what wish lists they wanted.
    • I would schedule follow-up meetings if needed, especially if multiple InfoPath forms would be modernized together.
  3. Armed with a good understanding of the target forms, we would meet internally to debrief and propose a new solution.
    • Sometimes a modern SharePoint list would suffice, but most frequently, a canvas app would be required to replace existing forms, especially when multiple or similar InfoPath forms needed to be modernized.
    • Our Solution Architect would also check data integration or connection with other systems outside the form(s), ensuring that such integration would continue to work in the new solution.
    • Power Automate would be used for associated workflows, such as email notifications, permission/role-based access control, and user profile fields.
  4. After our discovery team agreed that a canvas app should be used, I would create an Excel spreadsheet to document app requirements, while our UX Architect would start to create a prototype.
    • The prototype would illustrate our design ideas, provide a visual representation, and include some interactions of the new solution.
    • I always created at least three worksheets in the Excel spreadsheet:
      • Background: Summary of what we learned in client meetings, such as the purpose of the existing form(s), description of form users, and form owners’ contact info.
      • URLs: Links to the existing form(s) and SharePoint site(s).
      • Acceptance Criteria: Detailed requirements of the canvas app.
    • During this step, the UX Architect and I would meet multiple times to ensure that the documented requirements and prototype would match.
    • When needed, we would consult our Solution Architect to ensure that the requirements and prototype took full advantage of the Power Platform capabilities.
    • I acted as both a BA and UX Architect for several forms, documenting requirements and creating prototypes, which simplified this step.
  5. When we met with stakeholders again, we showed them both the prototype and requirements and emphasized that no actual coding had occurred. Doing so would encourage them to provide any additional suggestions if needed so that the new solution would meet their business needs.
    • The Excel file and prototype complemented each other well, especially in areas where the prototype did not cover. For example, instead of making workflows work in the prototype, which would require a lot of coding, I would specify that in a requirement explaining when and who would be notified when a form was submitted.
    • Sometimes we needed to go back and adjust our prototype and requirements before we met with the stakeholders again to get their final approval to our proposed solution.
  6. As the last discovery step, we would meet with our Developers and QA Test Engineer, walking through the prototype and detailed requirements accessible from a SharePoint document library.
    • The meeting acted as a knowledge transfer session from the Discovery team to all other members.
    • Based on the information, Developers would create tasks in the Azure DevOps (ADO) to restructure data, estimate needed screens or forms, report data in Excel or Power Bi, and create flows.
    • Test Engineer would create the necessary test plan, cases, and steps in ADO.

Ideally, our Discovery team could answer all questions from our Developers and Test Engineer at this step. However, from time to time, they would ask us a few questions or details that we could not answer, which required us to go back to client stakeholders for further clarification. When that happened, I would update the Stakeholder Interview Template to cover such questions in future discovery.

Examples of such questions included:

  • Will form submitters be allowed to edit their submissions?
  • Should they be allowed to save a draft before submission, or should they fill out the entire form in one sitting?
  • Should there be an app Administrator screen so that stakeholders could make future updates easily within the app, or will they be comfortable enough to make updates directly from the back-end, such as a SharePoint list?

In Summary

As described above, having a designated Discovery team in a project with members specializing in UX and technology solutions worked well and significantly contributed to our project success. In general:

  • Following a user-centered design/discovery process helped the project teamwork efficiently, avoided surprises in later development and testing, and saved overall project time.
  • It was important for project discovery to start at least a couple of weeks ahead of the rest of the team.
  • Involving client stakeholders early and throughout discovery was crucial in ensuring that the new solution would meet the client’s business needs.
  • Discovery artifacts, such as the prototype and requirements, should be available at a central location so that all team members could easily refer to them and clearly understand how the new solution should function.

In Part 2 of this blog series, I will compare my experience prototyping in Axure and the Power Platform. I will also share a few form design and content development best practices that we implemented when we modernized InfoPath forms to Power Apps.

Pluralsight Course Overview

Robotic Process Automation (RPA) has been a top tech trend over the last few years, and we are seeing great interest in augmenting RPA with Artificial Intelligence (AI) to make automation more resilient. While Power Automate (previously called Flow) has been around for a while, RPA capabilities have been a recent addition, allowing you to automate all repetitive desktop processes. You can choose between prebuilt drag-and-drop actions or record your own desktop flows.

In this course, Intelligent Automation: RPA and Beyond with Power Automate, you will learn the skills you need to work effectively with Power Automate Desktop Flows and AI Builder.

  1. First, you will motivate the importance of intelligent automation with RPA and AI.
  2. Next, you’ll explore Power Automate capabilities.
  3. Finally, you will walk through the end-to-end example of an intelligent automation reference solution.

When you’re finished with this course, you will have the skills and knowledge necessary to use Power Automate to streamline desktop tasks for your organization.

View the course, Intelligent Automation: RPA and Beyond with Power Automate, on Plursalsight.

Below is a short clip from the course:

About the Author

This course was authored by Vishwas Lele from AIS.

Vishwas would like to give a special thank you to AIS colleagues – Sanjeev Bhutt and Himani Talesara – for their assistance with this course.

Check out more courses from Vishwas:

In this blog post, I’m going to discuss the new feature currently in public preview – “Connection References (Preview).” This feature was released to maintain a level of abstraction between flows and the connections they are using. Connection references come in handy when a user wants to move across environments, update the flow definitions, or automate the deployment using pipelines for secure and healthy ALM.

A connection reference is a component of the solution that contains information about a connector. Both actions within a Power Automate flow and Canvas Application bind to a connection reference. You can import your connection reference into a target environment with no further configuration needed after the import is successful. To change a specific connection associated with a Power Automate Flow or Canvas Application, you can edit the connection reference component within the solution. Firstly, we need to understand how flows and connections are associated with each other. Every action inside a flow is bound to a connection that it uses for the “Execution.” Users need to rebind every operation for the connection after import across the environments (Overriding all the customizations). Below is the image reference for the same.

Rebinding every action to a connection

If we look at the larger view, it seems to be like a scenario defined by the below image.

Larger view at connection reference

When we move flows (part of the solution) across the environments, all links between the triggers, actions, and the connection are severed. We need to rebind all the links as soon as the import is successful in the target environment. But in the case of the “Connection Reference,” it provides the abstraction layer between the actions and the connections. As soon as we move across, the solutions link between the actions & connection references severed, but connection reference and connection remain intact. So, after the import is successful, it will automatically make links of the actions with the connection reference of the target environment, thus avoiding all the rebinding & reconfiguration.

Mostly, users get confused between CDS connectors’ current environment and using connection reference for the CDS connector. Are they the same, or are they different? A CDS current environment connector provides access to the org-based database on Microsoft Common Data Service in the current environment. We can use this connector to connect to the database and perform various operations on data using the connection to the backend provided by this connector. Coming onto “Connection References,” they act as a variable that contains information about the connectors. It includes the name of the connector we are using as well as the connection to that connector. So, both of them are different concepts.

Demo describing the use of the “Connection References (Preview)”

  1. Go inside your sample solution. Create a connection reference by clicking on “New”. Fill out the required details.
    Demo Step 1 Step 1 New Connection
  2. Inside the solution, there is a flow using the connection of any user as a direct connection which was prior connection reference was introduced. And have created a new flow using the connection reference created in step – 1.
    Without Reference

    Without a Connection Reference
    Demo Step 4

    With Connection Reference 

  3. Import the solution to the target environment. During the import, it will ask for the connection reference to be used in the target environment. Select one from the list or create a new one at the time of the import and select import.
    Demo Step 3 Import Solution
  4. Now make some changes to the solution in Dev Env. After you make certain changes and want to re-import the solution again to target env by overriding the customizations. You will observe the impacts on the two different flow in the following way.
    Demo Step 4 With

Without a Connection Reference

Demo Step 4 With

With a Connection Reference

The flow with the direct reference to connections users needs to rebind all the connections of every action. In contrast, inflow using the “Connection Reference,” all connections are set up automatically. There is not to reconfigure the flow after the import. If you want to update the connection reference (if your reference account has an issue) in the target environment and your solution is managed in the target environment.

Follow the below steps:
Go to: Default > Filter by Connection Reference (Preview) > Select your connection reference> Update the selected Connection reference > Make a new connection > Save And Close.


While connection references are in preview, one connection reference can be used within a maximum of 16 flows. If the same connection needs to be used in more than 16 flows, then create another connection reference with a connection to the same connector. There is no limit to the number of actions in each flow associated with the connection reference. Thank you for reading!