In this article, I will show you:

  • How to restrict users from accessing certain features in a canvas app, while other users can still see and use features.
  • How to use SharePoint action in Power Automate to authenticate a user.

Why Restrict Access?

In any App, there’s always more than one type of user. For example, there will be customers, staff, administrators, and so on in an event management application. An administrator will have access to everything; meanwhile, staff will have limited access. However, a customer can only access his data.

Therefore, we need to make sure that we restrict users from interacting with specific data or features. For example, using Power Automate, we can hide anything in our Canvas App from users so that they do not interact with it. But how do we know who has access to it and who does not? Through a SharePoint group!

We will create a SharePoint group and add the users who have complete access to the app, but before we move ahead, let us understand what SharePoint groups offer:

  • There are four types of SharePoint groups: Viewers, Visitors, Members, and Owners.
  • Each group has different permission levels like view-only, read, edit and full-access.
  • You can assign a permission level to multiple users by simply moving them to a group.

Now that we know the basics let us break this article into pieces:

  1. Create a SharePoint group
  2. Create a flow to authenticate users.
  3. Create a simple canvas app.
  4. Hide elements in the canvas app using global variables.
  5. Bonus Tip

One: Create a SharePoint Group

Follow this article to create a SharePoint group.

Apart from group names and descriptions, SharePoint allows you to choose permission levels. You can select any options based on your requirements.

After creating the group, add a user to it.

Create group and add user in SharePoint Group

Verify if in Environment

Note: Make sure this user is already present in your environment.

Two: Create a Flow to Authenticate Users

Create an instant flow with PowerApps as a trigger and add three variables.

Instant Flow in PowerApps

  • Email: This will be an input from the canvas app.
  • UserInfo – We’ll store user information that SharePoint API will fetch us.
  • ShouldAccess – This will initially be false.

Note: You can name these variables however you like.

Now Add the ‘Send HTTP Request to SharePoint’ action.

Add Send HTTP Request action

Here we have some fields to fill. These fields are crucial, and we primarily run into errors in this step. So be careful.

Let’s break it down one by one.

  1. Site Address: Select the site from the dropdown. Select the site where your group is.
  2. Method: Select the GET method. Since we are requesting SharePoint to provide user data.
  3. URI: We need to give the URI, which will fetch us data from the SharePoint group’s list.

URI Structure

Functions of URI Structure

  • /api/web/sitegroups – Take you to the site groups of SharePoint.
  • GetByName(‘’) – This function will go to a specific group on your site.
  • Users – It will take you to the user’s list in the group
  • $filter = Email eq ‘’ – This is a filter query that will check for the email id provided by you. It will fetch user details; otherwise, it will send a blank response.

Note: The URI structure could be tested by simply pasting it in your browser. But don’t forget to add the SharePoint, Site Address + Uri.

It should return a json structure with user details. If it doesn’t, then your link is broken. Now save and test your flow.

Save and test your flow

On a successful run, check the http response body. If the user is present, it will return the result like this:

Check HTTP response body

If the user is not present, then you will see an empty array like this:

User not present in HTTP

Now let us add a condition where we will check if the result is empty or if it returns the information about a user.

Add Condition

In the ‘value’ property of the ‘Condition,’ add an expression. This expression will extract the length of the ‘results’ array from the http response.




If the length is 0, the user is not present in the SharePoint group. This is all we need to authenticate a user. Now, if you remember, we already initialized a ‘ShouldAccess’ variable as false. Therefore, we will only update this variable as true when the above condition is false, which means the ‘results’ array is not empty.

Update variable

So, in the ‘No’ section after the condition. Then, add the ‘Set variable’ action and update the ‘ShouldAccess’ variable as true. We are almost done, but let us send the response to the canvas app using the ‘Respond to PowerApps’ action.

Respond to PowerApp or flow

We are simply returning our ‘ShouldAccess’ variable to the canvas app. Canvas will treat this as a signal. Based on the value of this variable, it will decide if the user should be granted access or not.

Three: Create a Simple Canvas App

Visit and create a blank canvas app. Then, add two buttons on the canvas.

Add two buttons to PowerApps Canvas

Test App and change color of buttons

I like playing with colors, hovering colors, and so can you. Now onto the last step!

Four: Hide Elements in the Canvas App Using Global Variables

Select your current screen -> On Visible property -> Action -> Power Automate -> Add Test Flow

Adding a test flow in PowerApps

Check Flow for Mistakes

After the flow is being added, you will see this message. This means you are a genius and have made no mistakes so far.

Complete flow and testt

Now in the formula bar of ‘On Visible’ property, add this formula:

Set(CheckUser, TestFlow.Run(User().Email)); 
        Lower(CheckUser.shouldaccess) = "true", 

Check for OnVisible flow

Let’s understand the formula:

Set(CheckUser, TestFlow.Run(User().Email)) – We are storing the response from flow in a variable called CheckUser. User().Email is an input parameter to the flow.

Set(IsVisible) is another global variable we are using to check if the response is true or false. We will use this variable on Admin Button to hide it from staff.

Let’s take a look at how:

Test the true PowerApps flow
In the formula bar, remove ‘true’ and write the name of our global variable ‘IsVisible.’

Test the IsVisabile Variable

As soon as you add this, the Admin Button will become invisible.

Now save the app and reload the page. Upon reloading, it will run the flow, and since you are an admin, the ‘Admin’ button will be visible to you. Test this using different users as well to see the difference.

Step 5: Bonus Round!

There might be a few scenarios where you don’t want to hide the features entirely from the user but also want to restrict them from using them. In such a case, you can use the DisplayMode property of the admin icon.

If(IsVisible, DisplayMode.Edit, DisplayMode.Disabled)

Disable DisplayMode

Visible Admin icon

Look at that! Check out our very own partially visible admin icon.

On that note, I hope I could break down the mind-boggling stuff you may have read before this article.

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.

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!

This blog is a step-by-step walkthrough of building a fully functioning leave request app for any organization with a vacation, sick leave, military leave, bereavement leave, holidays, Jury Duty, and so on. This app will include a solution in the Common Data Service, a Model-Driven App, a Canvas App, and Power Automate. The Canvas App is for employees to submit a request. The Model-Driven App will be a back-office system used by admin or supervisors to check everyone’s requests. The Power Automate flow will trigger an approval email to the employee’s supervisor and an automated email to the employee once the supervisor has either approved or rejected the leave request.

The app’s flow will start with the employee using the Canvas App to submit a leave request form. Once that form is submitted, an email is sent to the supervisor, and, simultaneously, a new row is added to the Model-Driven App with the new leave request entry. Once the supervisor has approved or rejected the request, the employee will receive an email with the decision.


  1. A Microsoft PowerApps Trial Plan 2, this can be a Free Trial
  2. Ensure you are using an environment with a database

Common Data Service (CDS)

  1. Navigate to
  2. Create a New Solution called “Leave Request Solution”
    1. Create a New Publisher called “Leave Request App”Create a New Publisher
  3. Select New > Entity name it “Leave Request Entity” and Enable Attachments
    Enable Attachments CDS
  4. Select Add Fields
    Add Fields DSC
  • Add Field: First name
    • Data Type: Single Line Text
    • Required
  • Add Field: Last name
    • Data Type: Single Line Text
    • Required
  • Add Field: Email
    • Data Type: Email
    • Required
  • Add Field: Supervisor Email
    • Data Type: Email
    • Required
  • Add Field: Start date
    • Data Type: Date Only
    • Required
  • Add Field: End date
    • Data Type: Date Only
    • Required
  • Add Field: Request Type
    • Data Type: Option Set
      • Create New: “Request Type”
        Request New Option
    • New Option: Vacation Leave
    • New Option: Sick Leave
    • New Option: Military Leave
    • New Option: Bereavement Leave
    • New Option: Jury Duty
  • Add Field: Work Items
    • Data Type: Multiline Text
    • Required: Recommended
  2. Navigate to the Views tab
  3. Select Active Leave Request Entities
    Leave Request Entity
  • Right-click on Created On Column > Remove
  • Add Last Name by clicking the field on the left
  • Add Email by dragging the field to the editor
  • Add Start Date
  • Add End Date
    Add Start and End Date
  1. Once your View looks like the above, click Save, Publish, then Back
  2. Navigate to the Forms tab
    1. Click on the row with the Form type “Main”
      Form type “Main”
    2. Add all custom fields by clicking them directly on the left
    3. Select the section so that it is outlined in purple
    4. Click Formatting on the right, select 2 columns
  3. Once your Form looks like the above, select Save, Publish, then Back

Model-Driven App

  1. Navigate to the “Leave Request Solution”
  2. Select New > App > Model-Driven App
  3. Name it “Leave Request Back Office”
  4. Check “Use the existing solution to create the App”
  5. Select Next
  6. Select Solution: * “Leave Request Solution”
  7. Select Site Map to configure it
    Select Site Map to Configure

    1. Select the pencil next to New Subarea
    2. Select the “Leave Request Entity” from the dropdown on the right
      Leave Request Entry from dropdown
  8. Publish, and Save and Close
  9. In the App Designer view, select Publish then Play
  10. Select New
    1. Add test data
    2. Select Save & Close

Canvas App

  1. Navigate back to the “Leave Request Solution”
  2. Select New > App > Canvas App > Tablet form factor
  3. Select the Insert tab > Forms > Edit
  4. A box will appear in the editor, select Connect to data
    1. Select “Leave Request Entities” on the left
    2. Under Data source on the right, select “Leave Request Entities”
    3. Select Edit Fields
    4. Add the remaining fields in the popup modal
    5. Set Default mode to New
    6. Change name to “Leave Form”
      Change Name to Leave Form
  5. Navigate to Insert tab > Button
    1. Select OnSelect from dropdown
    2. Type “SubmitForm(‘Leave Form’);Navigate(Screen2);” in the functions(fx) box
      Functions box

      1. Select Text from dropdown and type “Submit Request”
  6. Navigate to Insert tab > New Screen > Success
  7. Navigate to the File tab > Save > Publish > Play
    Save and Publish, then play
  8. Add test data, select Submit, navigate back to the Model-Driven App to see the new entry

Power Automate

  1. Navigate back to the “Leave Request Solution”
  2. Select New > Flow
  3. In the search box type “When a record is created” and select the Common Data Service option
    Common Data Service Trigger Box
  4. Fill in the trigger box:
  5. Select New Step
  6. Then the Choose an Action box, type “Start and wait for an approval” in the search box and select it
  7. Fill in the action box using the Dynamic Content box
    1. Click inside the input field and then select the correct dynamic field from the Dynamic Content popup box
      Dynamic Content Box
  8. Select New Step
  9. Select Condition
  10. Fill in the boxes:
    Fill in the Boxes for the Trigger
  11. Select Save >Test > Check “I’ll perform the trigger action” > Select Save & Test
  12. Navigate to your Canvas App, select Play, add test data, and Submit Form
  13. You should see an approval email in the inbox you sent the supervisor email to, select Approve
    Approve Email
  14. Another email will be sent to the employee’s email with the response
    Approved Request

Final Thoughts

Congratulations! You have completed the Leave Request app using the Common Data Service, a Model-Driven App, a Canvas App, and Power Automate. You have a fully functioning application that can be used right away! The next steps would be to implement a status field where the Approve or Reject decision will be updated in the Model-Driven App so supervisors can keep track of any pending requests. This app can be adjusted to your organization’s needs and requirements, but this app is a great starting point.

Discover how we helped a Fortune 100 Insurance Company modernize their InfoPath forms with Power Platform.

Passing just about anything from Power Apps to Flow with the newly released JSON function

In this article, I will show you how we can send data from a Canvas App using the freshly released JSON function. I will pass data from the data table (of a SharePoint List), microphone (audio recording), and camera control (photo) to an MS Flow. A condition logic is set up in Flow to check the file type and create those accordingly in a dedicated SharePoint Library.

This article focuses on a canvas app and a flow. We will look at the component-wise structuring of both the app and the flow to achieve the objective.

Canvas App

Let’s look at the control-wise screens and functions used in the Canvas App.

  1. Data from a SharePoint list is displayed on a Gallery control in the app. A user can export this data to a PDF file and save it to SharePoint Document Library, and download it in the browser window.

Gallery Control

Here, we have a Gallery (‘Gallery2’) control that is populated with the data from a SharePoint List. The data is filtered to show only the first 10 records. The expression used on the ‘Items’ property of the Gallery control is:


Explanation: Get the first 10 items from the ‘OrderDets’ SharePoint list and get the columns as specified.

The ‘Create PDF’ button creates a local collection and then triggers an MS Flow and passes the collection as an argument along with the desired file name using the JSON function. Finally, once the PDF is created and the Flow is executed successfully, the PDF file is opened in a new tab of the browser. The expression used on this button is:


Explanation: The ‘ClearCollect’ function creates a collection named ‘PDFCollection’ and this stores the data in the gallery control and the name of the PDF file. The name of the PDF file is a concatenated string with the naming convention of ‘Test123-today’s date.pdf’. The ‘URL’ key inside the ‘PDFCollection’ stores string type value for the table formatted Gallery items, using the JSON function. This value is later parsed as JSON while sending as an argument to the Flow. The ‘Launch’ function opens a new browser window to launch the newly created PDF file’s URL received as a response from the ‘CreateFilesSharePoint’ flow.

  1. The Microphone control on the app is used to record audio. Multiple recordings can be created and played/viewed on the gallery control.

Microphone Gallery Control

Here, we have a Microphone control ‘Microphone1’ to record the audio inputs and store that into a local collection ‘AudioCollection’. The Expression used on the ‘OnStop’ property of the Microphone control is:


Explanation: The ‘Collect’ function updates a collection ‘AudioCollection’ to store the audio recordings with the unique file name. The filename is a concatenated string of ‘Audio-Today’s date-index of the audio file.mp3’.

The ‘Submit’ button triggers the Flow and creates all the audio recordings as separate files on the SharePoint document library. The Expression used on this button is:


Explanation: Here the JSON function converts the audio file URL to binary data and sends the ‘AudioCollection’ data to the ‘CreateFilesSharePoint’ flow.

The ‘Clear’ button clears data from the ‘AudioCollection’.

  1. The camera control is used to click photos in the canvas app. Multiple pictures can be captured and viewed on the Gallery control.

Camera Gallery Control

Here, we have a camera control ‘Camera1’ to capture a picture and store it into a local collection ‘ImageCollection’. The Expression used on the ‘OnSelect’ property of the Camera control is:


Explanation: Collect function updates the ‘ImageCollection’ collection with the unique file name and the URL of the photo taken from the camera control. The name of the file is a concatenated string of ‘Image-Today’s Date-Index of the photo in the gallery control.jpg’.

The ‘Submit’ button triggers the Flow and creates all the images as separate files on the SharePoint document library. The Expression used on this button is:


Explanation: Here, the JSON function converts the image file URL to binary data and sends the ‘ImageCollection’ data to the ‘CreateFilesSharePoint’ flow.

The ‘Clear’ button clears data from the ‘ImageCollection’.

MS Flow

Coming to the ‘CreateFilesSharePoint’ flow: This flow is triggered by the button controls on the different screens in the Canvas App.

Action 1: Initialise a variable -> accommodates the input coming from the canvas app.

Action 2: Initialise a variable (2) -> To get the string to send a response back to the canvas app.

Action 3: Parse JSON: Get the dynamic data by parsing the data received from the canvas app according to the schema where we have an array that contains objects with the attributes: ‘Name – Filename’, ‘URL – Filecontent’.

Flow 1

Action 4: Apply to Each control: Iterate over each file item from the body output of the Parse JSON function.

Action 5: Condition control within the Apply to each Control: Split the file name and check if the extension is a PDF file.

If No,

Action 6: Create File 2 in SharePoint: to create a file for the image/ audio type in the defined library. If Yes,

Action 7: Parse JSON 2: The data content passed from the Power Apps as the URL key is now being parsed as individual elements to create an HTML table and then finally create a PDF file out of it.

Action 8: Create HTML Table: Creates an HTML table with the column names as headers and gets the data from the Parse JSON 2 action.

HTML Table from Parson JSON

Action 9: Create File in OneDrive: To create a temporary HTML file from the HTML table generated in the previous step and store it in the ‘Hello’ folder on the OneDrive.

Action 10: Convert File in OneDrive: To convert the previously created HTML file to a PDF document.

Action 11: Create File 2 in SharePoint: To create the PDF file from the converted file from the previous action. The file is stored in the specified document library on SharePoint.

Action 12: Delete File from OneDrive: To delete the temporary HTML file that was created in Action 9.

Action 13: Get file Properties SharePoint: To get the URL of the PDF file created in SharePoint.

Action 14: Set Variable: Set the URL to the file as a string value.

Create and Transform Files

Action 15: Respond to Power Apps: Send the URL of the file created on SharePoint to Power Apps. (Outside of the apply to each control)

Respond to PowerApps

In this blog, we have seen how we can use the JSON function to pass data from Power Apps to Flow. We were able to successfully send binary data (image files, audio recordings) and a gallery data table. We can also send collections, data directly from data sources with appropriate filters, etc. The attributes that can be sent via the JSON function does not support sending attachments, nested arrays/objects.

I hope you found this interesting and this helped you. Thank you for reading!