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!