It was taking a long time, and even with careful work, small errors still occurred, such as incorrect amounts, missed dates, or incomplete entries. As volume increased, it became clear that this manual process was unsustainable.

That’s when I suggested building a simple automation using Power Automate and AI. Instead of handling invoices manually, we created a solution that lets users upload invoices as PDFs to a SharePoint library.

From there, the flow runs automatically, reads the invoice using AI, extracts all the important details, and stores them in a structured SharePoint list.

Extract Data from PDF Invoices Automatically Using Power Automate

What We Are Building

Here’s the full flow in simple terms:

1. User uploads an invoice PDF to the SharePoint Document Library
2. Power Automate triggers automatically
3. The file content is sent to AI
4. AI extracts structured invoice data
5. Data is stored in a SharePoint list

We are not using the default invoice model. Instead, we are using a custom AI prompt, which gives you more flexibility and control.

Create a SharePoint Document Library

Create a SharePoint document library where users will upload invoices.

Create a SharePoint List for Extracted Data

Create a SharePoint list to store all extracted data.

Add These Columns:

Note:

When I was building this solution, I didn’t just randomly add columns. I looked at the invoice format the client was using and then designed the SharePoint list based on that structure. The idea was simple whatever information exists in the invoice should have a proper place in SharePoint so that we don’t lose any important data.

You can follow the same approach. Your columns should always be based on your invoice format. If your invoices have different fields, you can adjust accordingly.

Create Extract Data from PDF Invoices Flow

Now that our SharePoint library and list are ready, let’s build the actual flow. This is where everything comes together.

The idea is simple: as soon as a file is uploaded, the flow should pick it up, read it using AI, extract the data, and store it in your SharePoint list.

Step 1: Create a New Flow

1. Go to Power Automate and create a new automated cloud flow.
2. Choose the trigger: When a file is created (properties only)
3. Then configure:
   • Site Address → Your SharePoint site
   • Library Name → Your Invoice Document Library

This ensures the flow runs automatically whenever a new invoice is uploaded.

Step 2: Get File Content

1. Add action: Get file content
2. Then configure:
   • Site Address → Your SharePoint site
   • File Identifier → Select Identifier from the trigger

This step is very important. The trigger only returns file metadata (like name and path), but the AI needs the actual file to read the invoice.

Step 3: Run a Custom AI Prompt

Now we move to the core logic.

1. Add action: Run a prompt

2. Expand the prompt and select + New custom prompt.

3. Then, under the instructions, add the following instruction:
4. Also, add an input parameter like: Document Content

You are an AI that extracts structured data from invoice documents.

Extract the following fields from the invoice:

- Invoice Number
- Invoice Date
- Due Date
- Vendor Name
- Vendor Address
- Customer Name
- Customer Address
- Subtotal
- Tax Amount
- Tax Percentage
- Total Amount
- Currency
- Bank Name
- Account Number
- IFSC Code
- UPI ID
- Line Items (Description, Quantity, Rate, Amount)
- Item Count (total number of line items)

Rules:
- Return ONLY valid JSON (no explanation).
- If any value is missing, return an empty string "".
- Dates should be in YYYY-MM-DD format.
- Numbers should not contain commas.

Output format:

{
  "InvoiceNumber": "",
  "InvoiceDate": "",
  "DueDate": "",
  "VendorName": "",
  "VendorAddress": "",
  "CustomerName": "",
  "CustomerAddress": "",
  "Subtotal": "",
  "TaxAmount": "",
  "TaxPercentage": "",
  "TotalAmount": "",
  "Currency": "",
  "BankName": "",
  "AccountNumber": "",
  "IFSCCode": "",
  "UPIID": "",
  "ItemCount": "",
  "LineItems": [
    {
      "Description": "",
      "Quantity": "",
      "Rate": "",
      "Amount": ""
    }
  ]
}

5. On the right side (Model response settings): Set Output type → JSON
6. Also, rename the prompt to something meaningful, like: Extract Invoice

Now that your prompt is configured, it’s time to test. Upload one of your sample invoice PDFs to the Document input. Check the Model response side, it is giving the correct json.

7. Then, in the Run a prompt action, select the prompt you created (for example, Extract Invoice).

After that, you need to pass the input file to the AI so it can read the invoice.

8. In the Document input, select:
   • File Content from the previous Get file content action

base64(body('Get_file_content'))

This step is very important. Without passing the file content, the prompt won’t have anything to process, and you won’t get any output.

Once this is set, the AI will take the PDF file, read the invoice details, and return the structured JSON based on your prompt.

Step 4: Create an Item in SharePoint

Now that our AI prompt is working and returning clean JSON, the next step is to store that data in our SharePoint list.

1. Add a new action: Create item
2. Then configure:
   • Site Address → Your SharePoint site
   • List Name → Extracted Invoice Data

Map the Fields

Now you need to map the output from the Run a prompt action to our SharePoint columns. Since your prompt is already returning structured JSON, you can directly use those values.

Map like this:

• Title → InvoiceNumber
• Invoice Date → InvoiceDate
• Due Date → DueDate
• Vendor Name → VendorName
• Vendor Address → VendorAddress
• Customer Name → CustomerName
• Customer Address → CustomerAddress
• Subtotal → Subtotal
• Tax Amount → TaxAmount
• Tax Percentage → TaxPercentage
• Total Amount → TotalAmount
• Currency → Currency
• Bank Name → BankName
• Account Number → AccountNumber
• IFSC Code → IFSCCode
• UPI ID → UPIID
• Item Count → ItemCount
• Line Items → LineItems

Handle Line Items

For the Line Items column (multiple lines), you need to convert the array into a string.

Use this expression:

string(body('Run_a_prompt')?['LineItems'])

This will store all the extracted line items in JSON format inside SharePoint.

Now map the additional tracking columns:

• File Name → File Name (from trigger)
• File Link → Link to item or file path
• Processed Date → use utcNow()
• Status → Processed

Testing the Complete Flow

Now that everything is set up, it’s time to test your flow end-to-end.

Upload one of your sample invoice PDF files to the SharePoint document library.

As soon as the file is uploaded, our flow should trigger automatically.

Verify the Flow Run

Go to Power Automate → Flow Runs and open the latest run.

Check each step one by one:

• Trigger → Confirm the file is picked correctly
• Get file content → Ensure file content is retrieved
• Run a prompt → This is the most important step

Open the output of Run a prompt and verify:

• JSON is valid
• All fields are present
• Values are correctly extracted

Check SharePoint List

Now go to your Extracted Invoice Data list.

You should see a new item created with:

• Invoice Number
• Vendor Name
• Dates
• Amounts
• Line Items
• File details

Everything should be populated automatically.

What If Something Is Not Working?

If data is incorrect or missing:

• Go back to the Run a prompt step
• Improve your prompt instructions
• Test again

Do not rush to change the flow logic. Most of the time, the issue is with how the prompt is written.

Conclusion

In this tutorial, I covered a complete end-to-end solution to automate invoice processing.

We started with a real problem where invoices were handled manually. Then we built a solution using Power Automate and AI.

I created a SharePoint document library to upload invoices and a SharePoint list to store extracted data. After that, we built the flow step by step, triggering when a file is uploaded, getting the file content, using a custom AI prompt to extract data, and finally storing that data in SharePoint.

We also tested the flow to make sure everything is working correctly.

That’s it. You now have a working solution that can automatically read invoice PDFs and store the data without any manual effort.

You may also like:

• Power Automate saves email attachment to SharePoint
• Delete all files in a SharePoint folder using Power Automate
• Send an Approval to a Microsoft 365 Group in Power Automate
• Send Approval to SharePoint Group Members Using Power Automate
• Copy List Items To Another List In SharePoint Using Power Automate

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

I’ve been through this migration more than once, and in this tutorial, I’ll walk you through exactly how to move your SharePoint Online list data into Dataverse. I’ll cover three methods so you can pick the one that best fits your situation.

Why Move from SharePoint Lists to Dataverse?

Before we get into the how, let me quickly explain why you’d want to do this in the first place.

SharePoint lists are great for simple scenarios — tracking tasks, logging requests, storing basic data. But they have limits:

• No real relationships — you can use lookup columns, but it’s not true relational data
• Limited row capacity — performance degrades noticeably past 5,000 items (the list view threshold)
• Weak security model — you can control access at the list level, but fine-grained, row-level security is painful to implement
• No server-side business logic — business rules, calculated rollups, and validations are hard to enforce
• Not ideal for model-driven apps — if you want to build enterprise-grade apps in Power Apps, Dataverse is the right foundation

Dataverse solves all of these. You get proper table relationships, row-level security, server-side business rules, and native support for model-driven Power Apps. Once you migrate, you’ll also unlock full Copilot Studio integration and better AI features across the Power Platform.

What You Need Before You Start

Let me save you some frustration. Before you begin the migration, make sure you have:

• A Power Apps environment — you need at least an environment with Dataverse enabled (not just Dataverse for Teams)
• The right permissions — you need the Environment Maker role or higher, plus write access to Dataverse
• Your SharePoint site URL handy — you’ll need it in every method
• A clean, well-structured list — if your SharePoint list has messy data, duplicate columns, or inconsistent values, clean it up first. Garbage in, garbage out.
• A Microsoft 365 or Power Platform license that includes Dataverse storage

Also, take a few minutes to map out your SharePoint columns to their Dataverse equivalents. Text columns map easily, but things like Person fields, Lookup columns, and Managed Metadata need special handling. I’ll flag those as we go.

Migrate SharePoint Online List to Dataverse

Here, I will show you two ways to migrate a SharePoint list to Dataverse, so you can choose the one that best suits your availability.

Method 1: Use “Create with SharePoint List” (The Quickest Way)

Microsoft added a really slick feature to Power Apps that lets you import a SharePoint list and create a Dataverse table—and a canvas app—in one go. If you’re starting fresh and just want to get your data into Dataverse quickly, this is the method I’d use first.

For this method i am using the Training Programs SharePoint list:

Here’s how to do it:

1. Go to make.powerapps.com and make sure you’re in the right environment
2. From the left-hand menu, select Tables.
3. Select Create with SharePoint List

Note:

This is not the only way to reach this screen. There is another way: go to Apps in the left-hand menu, then click + New app. From the dropdown, select Start with data → Create new tables → Import a SharePoint list.

4. Choose an existing SharePoint connection or create a new one
5. Enter your SharePoint site URL (e.g., https://yourorg.sharepoint.com/sites/HR)
6. Pick the list you want to migrate from the dropdown

7. You’ll see a preview of your table schema — review the column names and data types
8. Make any edits you need (rename columns, change data types, remove columns you don’t want)
9. Click Save and exit

Power Apps will do two things at once: create a Dataverse table based on your schema, and spin up a responsive canvas app using that table. It uploads the first 20 rows immediately so you can start working, and loads the remaining data in the background.

A note on Copilot: If Copilot is enabled in your environment, it will automatically suggest better data types for your columns. For example, if a column contains email-formatted text, Copilot will suggest mapping it as an email type rather than plain text. It also auto-populates choices for choice columns. This is surprisingly useful — I’d say it gets it right about 80% of the time, and the remaining 20% is easy to fix manually.

Limitations of this method:

• It works best for simple to medium-complexity lists
• Complex column types like Person/Group fields and multi-value lookups may need cleanup after import
• You can’t map to an existing Dataverse table — it always creates a new one

Method 2: Use Dataflows (The Most Reliable Method)

This is my go-to method for most real-world migrations, especially when you have a large list, complex column types, or you want to migrate data into an existing Dataverse table.

Dataflows use Power Query under the hood, which means you can transform, filter, and reshape your data before it lands in Dataverse. You have full control.

Step 1: Create a New Dataflow

1. Log in to make.powerapps.com
2. In the left navigation, click More if needed, then select Dataflows
3. Click + New dataflow and give it a name (e.g., “HR Requests Migration”)
4. On the data source screen, scroll down and select SharePoint Online List

Step 2: Connect to Your SharePoint List

1. Enter your SharePoint site URL and click Next
2. Choose Organizational account as the authentication method and sign in
3. Click Next

4. You’ll see all the lists available on that site — check the one you want to migrate.
5. Click on Transform data.

Step 3: Clean Up Your Data in Power Query

This is where Dataflows shine. You’re now inside the Power Query editor, and you can see all your SharePoint columns — including a bunch of internal system columns you don’t need.

Here’s what I typically do:

• Remove system columns you don’t need: columns like _UIVersionString, FileSystemObjectType, ServerRedirectedEmbedUrl — select them, right-click, and choose Remove columns
• Expand complex columns: Person/Group columns in SharePoint come in as records. Click the expand icon next to those columns and choose the field you actually want — usually Email for Person fields
• Handle Lookup columns: Lookup columns are also returned as records. Expand them and extract the Value (the display text) or the LookupId, depending on how your Dataverse table is set up
• Change data types as needed: if a column should be a date but came in as text, change it here

Step 4: Set the Destination

1. Click Next to get to the Map tables screen
2. Under Load settings, choose:
   • Load to new table if you want Dataflows to create the Dataverse table for you
   • Load to existing table if you already have a table in Dataverse and just want to fill it with data
3. If you chose an existing table, use the Column mapping section to match your SharePoint columns to your Dataverse columns — the system will auto-map what it can, and you fix the rest
4. For the primary key, map it carefully. If you have a unique ID from SharePoint that you want to preserve, map it here.

Step 5: Publish and Monitor

1. Click Publish — this kicks off the migration
2. Once published, find your dataflow in the list, click the three dots menu, and select Show refresh history to check if it ran successfully
3. You’ll see a timestamp, row count, and any errors

Pro tip: Dataflows can be set to refresh on a schedule. This is handy if you want to sync new SharePoint data periodically rather than doing a one-time migration. Once you’re satisfied, you can disable the schedule and treat it as a completed migration.

Method 3: Use Power Automate (Best for Attachments and Complex Records)

If your SharePoint list has attachments (file uploads stored against list items), neither of the above methods will handle those. This is where Power Automate comes in.

The idea is simple: you build a flow that reads every item from the SharePoint list, creates a corresponding record in Dataverse, and then attaches any files to that new record.

Ensure all columns in the SharePoint list are properly created in the Dataverse table.

The Basic Flow Structure

1. Trigger: Manually triggered (or recurrence, if you’re doing this in batches)
2. Action 1: Get items from SharePoint list (use pagination — set the top count to 100 or more and enable the Odata-skiptoken to loop through all items)

3. Then add Apply to each item and provide the body/value from the dynamic content of the Get items.
4. Inside the Apply to each add “Add a new row” and provide below:

5. Then add Get attachments for the current SharePoint item.

6. For each attachment: Get the attachment content, then create a note/annotation in Dataverse linked to the new record.

Handling the 5,000+ item scenario: If your list has more than 5,000 items, use a Do Until loop with a skip index variable. Start at 0, pull 100 items at a time, process them, increment the skip counter by 100, and loop until you’ve processed everything.

Handling attachments specifically:

Get attachments (SharePoint) → item ID from current loop item
Apply to each attachment:
  → Get attachment content (SharePoint)
  → Create annotation (Dataverse)
     - ObjectId: [Dataverse record ID you just created]
     - ObjectTypeCode: [your table's type code]
     - FileName: [attachment name]
     - DocumentBody: [base64 encoded content]
     - MimeType: [file type]

This method takes more time to build, but it’s the most complete migration you can do. Everything comes over — data, files, and all.

Handling the Tricky Column Types

Let me call out the columns that almost always cause problems during migration, and what to do about them.

Person/Group fields
SharePoint returns these as complex objects with DisplayName, Email, LookupId, and more. In Dataverse, you’ll typically have a Lookup to the systemuser table. The cleanest approach is to extract the email from the SharePoint output and then use a lookup in Power Query or Power Automate to find the matching Dataverse user record by email.

Lookup columns
In SharePoint, a lookup column points to another list. In Dataverse, the equivalent is a relationship between two tables. Before migrating, create the related Dataverse table first and migrate that data. Then, when migrating the parent list, use the LookupId from SharePoint to find the corresponding Dataverse row ID and set the relationship.

Multi-value lookup / multi-select choice
These are the messiest. A “multi-select people” or “multi-lookup” column in SharePoint doesn’t have a direct equivalent in Dataverse. You have a couple of options: flatten the values into a multi-select choice column, or create a proper many-to-many relationship table in Dataverse. The second option is more work upfront but much cleaner long-term.

Managed Metadata (Taxonomy fields)
Dataflows don’t handle these well. Your best bet is to treat them as text values during migration and then apply proper classifications in Dataverse afterward.

Attachments
As covered above, use Power Automate for these. Neither the “Create with SharePoint List” method nor Dataflows will migrate file attachments.

After the Migration: Things to Check

Once your data is in Dataverse, don’t just assume everything is fine. Here’s my post-migration checklist:

• Verify row counts — open your Dataverse table and count the rows. Compare with the SharePoint list item count.
• Check key columns — spot-check 10–20 records manually. Confirm that text, dates, choices, and lookup values all came through correctly.
• Test lookup/relationship columns — especially if you migrated related tables. Make sure the relationships are intact.
• Set up security roles — in Dataverse, access is controlled through security roles, not SharePoint permissions. Create or update roles to give the right users access to your table.
• Update your Power Apps — if you had a canvas app pointing at the SharePoint list, you’ll need to update the data source. In Power Apps Studio, remove the SharePoint connection and add the Dataverse table as the new data source. Then re-map your controls.
• Archive or retire the SharePoint list — once you’ve confirmed the migration is good, consider making the SharePoint list read-only or archiving it. Don’t delete it immediately — keep it around for a few weeks as a backup.

Which Method Should You Use?

Here’s a quick summary to help you decide:

Common Mistakes to Avoid

I’ve seen these trip people up repeatedly:

• Skipping the schema review — always check your column types before publishing. A date that comes in as text won’t cause an error, but it’ll cause pain later.
• Not creating related tables first — if you have lookup relationships, migrate the referenced tables before the parent table. Otherwise, your lookup mappings will fail.
• Ignoring duplicate detection — Dataverse has duplicate detection rules, but they don’t prevent duplicates; they only flag them. If you run a dataflow twice by accident, you could end up with doubled data. Use unique alternate keys on your table to guard against this.
• Forgetting about security roles — after migration, users who had access to the SharePoint list won’t automatically have access to the Dataverse table. You need to explicitly assign security roles.
• Migrating everything at once — for large, complex lists, migrate in phases. Start with the simpler columns, validate, then add the complex ones.

You may like the following Power Automate tutorials:

• Add Rows to Excel in Power Automate
• Check Site Permissions in SharePoint Online
• Create an HTML Table in Power Automate
• Expense Reimbursement and Approval using Power Automate
• Create Calendar Events from a SharePoint list using Power Automate

Migrating from SharePoint to Dataverse is one of those things that sounds intimidating but is very manageable once you understand the options. Start with Method 1 for a quick proof-of-concept. Use Dataflows when you need more control. And bring in Power Automate when attachments or complex transformations are involved.

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

It’s a really common requirement. Think about it: you’re building an app where users submit a project, and you want a folder automatically created in SharePoint to store all the related files. Or maybe you want users to type a folder name in a text box and click a button to create it on the spot. Super practical stuff.

The good news? There are three solid ways to do this. I’ll walk you through each one, with step-by-step instructions and real examples, so you can pick the approach that fits your use case best.

What You’ll Need Before Starting

Before we jump in, make sure you have:

• A Power Apps canvas app (or create a new one from scratch)
• A SharePoint document library (not a SharePoint list — folders live in document libraries)
• Appropriate permissions on the SharePoint site (at least Contribute)
• A Power Automate license

For this example, I have a SharePoint Document library called PDF Reports:

Create a Folder in SharePoint From Power Apps

Learn how to create folders in SharePoint directly from Power Apps using two simple and effective methods based on your use case and complexity.

Method 1: Trigger a Power Automate Flow from a Button (Recommended for Most Cases) in Power Apps

This is the most popular method, and honestly, the most flexible one. The idea is simple — you build a Power Automate flow that creates the folder in SharePoint, and then call that flow from a button in your Power Apps app. You can pass the folder name (and even a subfolder path) as input from the app.

This approach gives you more control, especially when you need to:

• Create nested folders or folder structures
• Check if a folder already exists before creating it
• Handle errors gracefully
• Return the folder path back to your app after creation

Step 1: Create the Power Automate Flow

1. Go to flow.microsoft.com and click + New flow > Instant cloud flow
2. Name your flow (e.g., “CreateSharePointFolder”)
3. Select Power Apps (V2) as the trigger and click Create

Step 2: Add an Input Parameter

In the Power Apps (V2) trigger:

• Click Add an input
• Choose Text
• Name it FolderName

This is how your Power Apps app will pass the folder name to the flow.

Step 3: Add the “Create New Folder” Action

1. Click + New step
2. Search for SharePoint
3. Select Create new folder
4. Fill in the fields:
   • Site Address: Select your SharePoint site
   • List or Library: Select your document library (e.g., Documents)
   • Folder Path: Click the Dynamic content panel and select FolderName (the input from Power Apps)

Step 4: Add a “Respond to a PowerApp or flow” Action (Optional but Useful)

If you want to confirm the folder was created or return the folder path back to Power Apps:

1. Add a Respond to a PowerApp or flow action at the end
2. Add an output — for example, a text field called FolderPath
3. Set its value to the Folder Path output from the Create new folder action (available in dynamic content)

Click Save, and you’re done with the flow.

Step 5: Call the Flow from Power Apps

Back in your canvas app:

1. Insert a Text input (txtFolderName) and a Button

2. Click the three dots (…) -> Power Automate in the toolbar
3. Select your newly created flow from the list

4. In the button’s OnSelect property, the formula will look like:

CreateSharePointFolder.Run(txtFolderName.Text)

If you set up the response action and want to capture the returned folder path:

Set(
    varFolderPath,
    CreateSharePointFolder.Run(txtFolderName.Text).folderpath
)

Step 6: Test It

Run the app, type a folder name, click the button, and check SharePoint. Done.

Want to create a subfolder? In the Folder Path field of the flow, just combine the parent folder and the input name:

/Documents/ParentFolder/FolderName

Or dynamically in the flow, use an expression like:

concat('/Shared Documents/', triggerBody()['text'])

When to use this method: For most real-world apps. It’s reliable, gives you error handling options, and works great for dynamic folder names, subfolders, and confirmation responses.

Method 2: Create a Folder Using REST API via Power Automate (Advanced & Flexible)

This is the method I use when I need full control over folder creation.

Instead of relying on the standard SharePoint action, you directly call the Microsoft Graph API using Microsoft Power Automate.

This approach is perfect when you need more than just basic folder creation.

You can:

• Create folders anywhere (SharePoint, Teams, OneDrive)
• Control what happens if the folder already exists (rename, replace, fail)
• Build dynamic folder paths
• Handle complex scenarios cleanly

This approach is less common but works when you want everything to happen within Power Apps, with no external flow dependencies.

Step 1: Create the Power Automate Flow

1. Go to flow.microsoft.com
2. Click + Create → Instant cloud flow
3. Name your flow (e.g., CreateFolderRestAPI)
4. Select Power Apps (V2) as the trigger. Click Create

Step 2: Add Input Parameters

• In the Power Apps (V2) trigger:
• Click Add an input
• Choose Text
• Name it: FolderName

Step 3: Add “Send an HTTP request to SharePoint”

Click + New step and Search: Send an HTTP request to SharePoint

1. Site Address: Select your SharePoint site
2. Method: POST
3. URI: _api/web/folders
4. Headers:

{
  "Accept": "application/json;odata=verbose",
  "Content-Type": "application/json;odata=verbose"
}

5. Body:

{
  "__metadata": {
    "type": "SP.Folder"
  },
  "ServerRelativeUrl": "/sites/dms-quality-compliance/PDFReports/@{triggerBody()?['text']}"
}

Make sure you replace the placeholders with your actual values:

• PDFReports → your document library name
• dms-quality-compliance → your SharePoint site name

Step 4: Call the Flow from Power Apps

Back in your canvas app:

1. Insert a Text input (txtFolderName) and a Button

2. Click the three dots (…) -> Power Automate in the toolbar
3. Select your newly created flow from the list

4. In the button’s OnSelect property, the formula will look like:

CreateFolderRestAPI.Run(txtFolderName.Text)

Step 6: Test It

Run the app, type a folder name, click the button, and check SharePoint. Done.

Important: This method uses the SharePoint REST API through Microsoft Power Automate, so the account running the flow must have proper permissions on the Microsoft SharePoint site and document library. Even if your setup is correct, you may see errors like Access Denied if the connection used in the flow does not have access. Also, make sure the ServerRelativeUrl starts with the correct site path (for example, /sites/dms-quality-compliance/…) and uses the exact library name like PDFReports.

When to use this method: Use this method when you need more flexibility than the standard SharePoint action, such as creating folders with dynamic paths or handling custom scenarios. It’s a good middle-ground option when you want more control, but still want to stay within SharePoint without using the Microsoft Graph API.

How to Create a Folder Structure (Multiple Nested Folders)

Sometimes you don’t just need one folder — you need a whole structure. For example, when a new project is submitted, you want to auto-create:

/Projects
   /ProjectName
      /Documents
      /Images
      /Reports

The cleanest way to do this is with Method 2 (Power Automate flow), and you just add multiple “Create new folder” actions — one for each folder in your structure.

In Power Automate:

1. First action: Create folder /Projects/ProjectName
2. Second action: Create folder /Projects/ProjectName/Documents
3. Third action: Create folder /Projects/ProjectName/Images
4. Fourth action: Create folder /Projects/ProjectName/Reports

Just make sure each step runs only after the previous one completes (Power Automate does this sequentially by default in a standard flow).

If the folder names are coming from form fields in your app, pass each one as a separate input parameter in the Power Apps (V2) trigger.

Check If a SharePoint Folder Already Exists Before Creating It Using Power Automate

This is something people forget about, and it causes errors when users try to create a folder that’s already there.

In Power Automate, here’s the pattern I use:

1. Add a Get files (properties only) action and filter by folder path
2. Add a Condition action: check if the output is empty (no results = folder doesn’t exist)
3. If true → run the Create new folder action
4. If false → skip creation or show a message

You can send a message back to Power Apps using the Respond to a PowerApp or flow action — something like “FolderAlreadyExists” — and then display a notification in the app using Notify(“That folder already exists!”, NotificationType.Warning).

Quick Comparison of All Three Methods

Common Errors and Fixes

• “Folder already exists” error in the flow: Use the check-before-create pattern described above, or set the conflict behavior to rename in the API call
• Blank folder name creates an error: Add a simple If(IsBlank(txtFolderName.Text), Notify("Please enter a folder name"), ...) before running the flow
• Flow not showing up in Power Apps: Make sure the flow is saved and turned on. Also confirm that the trigger is Power Apps (V2), not a different trigger type
• Patch method not working: Double-check that you’re connecting to a document library, not a SharePoint list. Lists handle folders differently

Conclusion

My personal recommendation for most scenarios is Method 1 — the Power Automate flow approach. It’s the most reliable, it handles errors well, and it’s easy to extend later (like adding subfolders or sending an email notification when the folder is created).

And if you’re comfortable with APIs and want maximum control, Method 2 via Rest API is worth exploring.

Whichever method you pick, the pattern is the same: collect the folder name from the user in the app, pass it to your creation logic, and handle the response gracefully.

Also, you may like:

• Parse JSON in Power Apps [10 Practical Examples]
• Dataverse Formula Column
• Migrate SharePoint Online List to Dataverse
• Build and Deploy a Smart HR Assistant Bot Using Copilot Studio
• Power Apps CountRows Function [Including the Delegation Fix]
• Power Apps Dropdown Show Only Unique Values
• Power Apps First Function

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

This is for the conversations where the interviewer leans forward and says, “Okay, but how would you handle that at enterprise scale?”

I’ve put together 35 questions that come up in senior and lead-level Power Apps interviews — the kind that test architecture decisions, ALM maturity, delegation gotchas, PCF, Dataverse modeling, and real governance. These are the ones that separate the people who’ve just used Power Apps from the people who’ve owned it.

Let’s get into it.

51 Power Apps Interview Questions and Answers For Experienced Developers

Let’s discuss the architecture & design of Power Apps in the interview questions and answers.

1. How do you decide between a Canvas App and a Model-Driven App for an enterprise requirement?

This one comes up a lot, and the honest answer is — it depends on your data model.

I go with a Model-Driven App when:

• The solution is heavily data-centric, and I’m already working within Dataverse
• I need built-in views, forms, and business process flows out of the box
• Role-based security at the row and column level is a hard requirement
• The app is expected to grow with a lot of tables and relationships

I go with a Canvas App when:

• The UI needs to be pixel-perfect and highly customized
• The data lives in non-Dataverse sources like SharePoint, SQL, or an external API
• The team wants a consumer-app-like experience (kiosk screens, offline scenarios, mobile-first)

The biggest mistake I’ve seen is using a Canvas App because “it’s more flexible,” even when the requirement maps perfectly to a Model-Driven App. You end up rebuilding features that Dataverse already provides for free.

2. How do you architect a Power Apps solution for thousands of concurrent users?

A few things I always think about here:

• Data source choice matters most. SharePoint doesn’t scale well beyond a few hundred concurrent users. For serious enterprise workloads, Dataverse is the right choice. It handles concurrency, has proper indexing, and supports server-side logic.
• Avoid client-heavy formulas. The more logic you push to the server — via Dataverse calculated columns, Power Automate flows, or stored procedures — the better the app performs at scale.
• Break the app into smaller, purpose-built apps. One massive canvas app is a maintenance nightmare and loads slowly. I try to keep apps focused on a specific task or persona.
• Use named formulas and global variables wisely. Don’t reload data on every screen load. Cache what you can with Collect and ClearCollect, but be deliberate about when to refresh.
• Environment segregation. Dev, Test, and Production should be separate environments with proper ALM pipelines.

3. How do you structure a multi-environment ALM strategy for Power Platform?

I follow Microsoft’s recommended pattern: Development → Test → Production, all managed through Azure DevOps or GitHub pipelines.

Here’s how I think about it:

• All development happens in individual developer environments or a shared dev environment.
• Components are packed into unmanaged solutions during development.
• When promoting to Test or Production, the solution is exported as a managed solution. This is non-negotiable for me — managed solutions prevent ad-hoc changes in production.
• I use solution layers deliberately. If I need to hotfix something in production, I track it and ensure it gets pushed back to the dev branch.
• Environment variables and connection references are set up from day one, so the same solution works across environments without manual reconfiguration.

One thing a lot of teams miss: the unmanaged layer always sits on top. So if someone makes a direct change in production and you later deploy a managed solution, the unmanaged layer wins. You need to be very disciplined about keeping production clean.

4. What is solution layering, and why does it matter in deployments?

Solution layering is how Power Platform manages components when multiple solutions touch the same object.

• At the bottom, you have the system layer — Microsoft’s base components.
• Above that are managed layers — your deployed solutions, stacked in import order. The last one imported wins in case of conflict.
• At the very top is the unmanaged layer — this always overrides everything else.

The problem? If a developer or admin customizes something directly in a production environment (bypassing the ALM pipeline), it creates an unmanaged layer that silently overrides your managed solution changes. You deploy an update, and nothing seems to change — because the unmanaged layer is blocking it.

Best practice: treat production like a read-only environment. All changes go through the pipeline.

Delegation & Performance

5. Explain delegation in Canvas Apps and how you handle it with large datasets.

Delegation is one of those things that trips up even experienced developers if they’re not intentional about it.

When you write a formula like Filter(MyList, Status = "Active"), Power Apps can either:

• Delegate it — meaning the filter runs on the server (SharePoint, Dataverse, SQL) and only matching records come back
• Process locally — meaning it downloads records to the app first, then filters them

The problem with local processing is the 500-record default limit (configurable up to 2,000). If your list has 50,000 items and your filter can’t be delegated, you’re only filtering against the first 500 or 2,000 records. The rest don’t exist as far as the app is concerned.

Here’s how I handle it:

• Design delegation-first. I check the delegation warning (blue underline) before any formula goes to production.
• Use delegable functions. With SharePoint, Filter, Search, Sort, and StartsWith are generally safe. Functions like CountIf, Mid, Len, and complex Or conditions are not.
• Offload to Dataverse views. Server-side views in Dataverse always return correct, complete results.
• Set the delegation limit to 1 during development. This forces non-delegable queries to fail visibly, so you catch issues early.
• For unavoidable non-delegable operations — say, you need to search inside a text field that isn’t indexed — I’ll often trigger a Power Automate flow that runs the query server-side and returns paginated results.

6. What are your go-to performance optimization techniques for Canvas Apps?

A few things I always check:

• OnStart bloat. I see apps where OnStart is doing 12 ClearCollect calls at load. Users sit on a loading screen for 8 seconds. Move data loading to the screen level (OnVisible) and only load what that screen needs.
• Concurrent function. Use Concurrent() to run multiple data calls in parallel instead of sequentially. This alone can cut load times by 40-60%.
• Gallery optimization. Don’t put complex formulas directly in gallery controls. Pre-process data into a collection and bind the gallery to that.
• Avoid unnecessary If nesting. Deep conditional trees slow rendering. Use Switch() where appropriate.
• Named formulas (App.Formulas). These compute lazily and only when needed, unlike OnStart which runs everything up front.
• Reduce the number of controls. Each control has a performance cost. Use galleries instead of duplicating controls.
• Profile with Monitor. Power Apps Monitor (formerly called App Checker + Network tracing) shows you exactly which calls are slow and where the bottlenecks are.

7. How do you deal with SharePoint’s 5,000-item list view threshold in Power Apps?

SharePoint enforces a 5,000-item limit on list views. If a query returns more than that, it can fail or return incomplete data.

In Power Apps with a SharePoint connector:

• The delegation limit caps results at 2,000 (at most), so in a way, you won’t even reach 5,000 from the app side — but you can still hit issues if your filters aren’t indexed.
• Make sure columns you filter on are indexed in the SharePoint list. Go to List Settings → Indexed Columns and add them.
• For large lists (100k+ items), I move to Dataverse or use Azure SQL with the SQL connector instead. SharePoint is not a database — it’s a document management system. If you’re using it as a primary data store for 200,000 records, it’s time to have a different conversation.

8. What’s your approach to offline capability in Canvas Apps?

Canvas Apps support offline scenarios through SaveData and LoadData functions, which persist collections to local device storage.

Here’s the pattern I use:

• On app load, check if the device is connected: Connection.Connected
• If online, load fresh data from the source and save a local copy with SaveData(MyCollection, "LocalCache")
• If offline, load from local storage with LoadData(MyCollection, "LocalCache", true)
• For writes, queue changes in a local collection. When connectivity is restored, iterate and patch them back to the source using ForAll + Patch

The tricky part is conflict resolution. If a record was updated by someone else while the user was offline, you need to decide: last write wins, or notify the user? I usually go with a timestamp check — compare Modified dates and surface the conflict to the user.

Dataverse Deep Dive

9. How does Dataverse’s security model work at a granular level?

Dataverse has one of the most sophisticated security models on the platform. It operates at multiple levels:

• Business Units — The top-level organizational boundary. Users belong to a Business Unit, and records are owned by a user or team within a Business Unit.
• Security Roles — Define what operations (Create, Read, Write, Delete, Append, Append To, Assign, Share) a user can perform on each table. Each operation can be scoped to: User (own records only), Business Unit, Parent: Child Business Unit, or Organization (all records).
• Field-Level Security — Lets you restrict read/write access at the column level. This is done through Field Security Profiles. Really useful for things like salary data or SSNs.
• Record Sharing — You can share individual records with specific users or teams, granting them access beyond what their security role allows.
• Hierarchical Security — A manager can automatically see records owned by their direct reports, based on the position hierarchy.
• Column Masking — A newer feature that masks column values (like a password field) even from users who have read access.

One thing I always stress: security roles are additive. If a user has two roles, they get the combined permissions of both. You can’t use one role to “subtract” permissions granted by another.

10. Explain virtual tables in Dataverse. When would you use them vs. a custom connector?

Virtual tables let you surface data from an external source (like an external API, Azure SQL, or a third-party system) directly inside Dataverse — without physically storing the data there. From the app’s perspective, it looks and behaves like a real Dataverse table.

I’d use a virtual table when:

• The external data needs to participate in Dataverse relationships or be used in views/forms of Model-Driven Apps
• You want to apply Dataverse security roles to the external data
• The external source already has an OData-compatible endpoint or you can build a virtual table provider

I’d use a custom connector when:

• I’m working in a Canvas App and just need to call an API
• The integration is action-based (trigger something, get a response) rather than data-browsing-based
• The overhead of building a virtual table provider isn’t justified

Virtual tables sound attractive but come with limitations — they don’t support offline, aggregations on virtual table data are tricky, and performance depends entirely on the external data source.

11. How do you design a Dataverse data model for complex relationships?

A few principles I follow:

• Normalize properly. Don’t create flat tables just because it feels easier. Use one-to-many and many-to-many relationships with proper junction tables.
• Use polymorphic lookups carefully. Dataverse supports Customer and Owner lookups (which can point to multiple table types). They’re powerful but can complicate views and forms.
• Elastic tables for high-volume, schema-flexible data. If you have logs, telemetry, or JSON-like data coming in at high volume, elastic tables (backed by Azure Cosmos DB) are a much better fit than standard Dataverse tables.
• Calculated vs. Rollup vs. Formula columns. Know when to use each. Calculated columns run on save, rollup columns aggregate child records (on a schedule), and formula columns are real-time but have limitations.
• Avoid many-to-many unless necessary. They add complexity to queries. Often, a well-structured junction table with extra metadata columns is cleaner.

12. What are elastic tables in Dataverse, and when do you reach for them?

Elastic tables were introduced to handle scenarios that standard Dataverse tables struggle with — massive volume, variable schema, and time-series data.

Under the hood, they’re backed by Azure Cosmos DB (NoSQL), which means:

• They can handle millions of records with fast writes
• Schema is flexible — different rows can have different columns (stored as JSON)
• Time-to-live (TTL) is supported natively, so records can auto-expire

I use elastic tables for:

• Audit logs and telemetry
• IoT sensor data
• Chat history or message threads
• Any scenario where you’re writing thousands of records per minute

What they don’t support: complex Dataverse relationships, rollup fields, and some standard query patterns. So they’re a specialist tool, not a replacement for regular tables.

Power Apps Component Framework (PCF)

13. Walk me through how you’d build and deploy a PCF control.

PCF controls are built using TypeScript (and optionally React) and follow a specific lifecycle. Here’s the high-level flow:

1. Scaffold the project using the Power Platform CLI: pac pcf init --namespace MyNamespace --name MyControl --template field (or dataset for grid controls)
2. Implement the control interface — the key methods are init, updateView, getOutputs, and destroy
3. Build and test locally using npm start watch — This spins up a test harness in the browser
4. Package into a solution: create a Power Platform solution project, add the PCF project, and build it with msbuild /t:build /restore
5. Deploy by importing the solution into the target environment

For Canvas Apps, the environment needs the PCF feature flag enabled by an admin first.

The updateView method is where most logic lives — it fires whenever the control’s input properties change. Keep it lean and avoid expensive DOM operations there.

14. What’s the difference between a field PCF control and a dataset PCF control?

• Field control — Binds to a single column value. You’re replacing or augmenting how a single field is displayed and edited. Examples: a color picker, a rating slider, a signature pad.
• Dataset control — Binds to a collection of records (like a view or subgrid). You’re replacing how data is displayed in a list. Examples: a custom Kanban board, a timeline view, a custom calendar.

Dataset controls are significantly more complex because you have to handle paging, sorting, filtering, and column metadata yourself through the dataset API. Field controls are simpler to start with if you’re new to PCF.

15. How do PCF controls interact with the Power Apps runtime? What lifecycle methods matter most?

The PCF runtime calls these methods:

• init(context, notifyOutputChanged, state, container) — Called once. Set up your initial DOM structure and event listeners here. notifyOutputChanged is your callback to tell the runtime that an output property has changed.
• updateView(context) — Called every time the context changes (user interaction, data refresh, property changes). This is your render cycle.
• getOutputs() — Called by the runtime after notifyOutputChanged fires. Return the updated output property values here.
• destroy() — Cleanup. Remove event listeners, cancel timers. Not doing this causes memory leaks.

The pattern is: user does something → your code calls notifyOutputChanged() → runtime calls getOutputs() → updated value flows back to the app.

Power Automate & Integration

16. How do you pass complex objects (arrays, JSON) between Power Apps and Power Automate?

Power Apps can only pass scalar values (text, number, boolean) directly to a flow — not arrays or objects natively. Here’s how I work around it:

• Serialize to JSON string. Use JSON(MyCollection) in Power Apps to convert a collection to a JSON string, pass it as a text parameter to the flow, then use json() expression in Power Automate to parse it back.
• Return complex data from flows. The flow can return a JSON string, and in Power Apps I use ParseJSON() to work with it. Just be aware that ParseJSON returns an untyped object — you’ll need explicit type casting.

For large payloads, this works fine, but watch out for the 2MB message size limit in Power Apps triggers.

17. How do you handle error handling and retry logic in Power Automate flows triggered from Power Apps?

This is an area where I see many gaps in production solutions.

In Power Automate:

• Turn on “Configure run after” settings. Each action can be configured to run after success, failure, timeout, or skipped states.
• Use Scope actions to group steps and wrap them in a try-catch pattern: one scope for the main logic, one scope that runs “after” the first scope fails.
• Use Compose + terminate to return structured error information back to Power Apps.

In Power Apps:

• Check the Status property returned by the flow. I always design flows to return at a minimum { "status": "success" | "error", "message": "..." }.
• Use IfError() and show a friendly error message rather than crashing silently.

Never show Power Automate’s raw error JSON to end users. Always handle it gracefully.

18. When would you use a custom connector vs. an HTTP action in a Power Automate flow?

I use a custom connector when:

• Multiple apps or flows need to talk to the same external API — having a connector centralizes the authentication and definition
• I want the API to be discoverable by other makers in the environment
• I want parameter validation and description metadata (makes it easier for others to use)

I use an HTTP action when:

• It’s a one-off call that only this flow will ever make
• I’m in a hurry and the connector overhead isn’t worth it
• The API doesn’t need to be reused or shared

Custom connectors support OAuth 2.0, API key, and basic authentication. HTTP actions are more flexible (you can construct headers manually) but less governed.

19. How do you implement row-level data security in a Canvas App backed by SharePoint?

SharePoint supports item-level permissions, but modifying them at the item level is expensive (breaking permission inheritance and creating management overhead) and doesn’t scale.

Here’s how I actually handle this:

• Separate lists by audience. If sales reps should only see their own opportunities, add a OwnerEmail column and filter with Filter(Opportunities, OwnerEmail = User().Email). Simple and delegable with SharePoint.
• Use SharePoint Groups. Control who has access to the list itself using SharePoint groups. Canvas Apps respect SharePoint list permissions — if a user can’t read the list, they can’t get the data.
• Power Automate as a secure data layer. For more complex scenarios, I route all data access through Power Automate flows that run with a service account. The flow applies the business logic for what the user can see and returns only that data. The user’s credentials never touch the list directly.
• Move to Dataverse if security is complex. If you need row-level security with any sophistication, Dataverse is the right tool. Trying to replicate Dataverse’s security model inside SharePoint + Canvas App gets messy fast.

Governance & Enterprise Topics

20. How do you set up DLP (Data Loss Prevention) policies for an enterprise Power Platform tenant?

DLP policies let admins control which connectors can be used together in a flow or app. They prevent sensitive data from leaking from a business system to a personal service (like someone connecting a SharePoint list to Gmail).

Here’s how I approach them:

• Three connector categories: Business, Non-Business, and Blocked. Connectors in the Business group can only connect to other Business connectors. Non-Business connectors can connect to each other. Blocked connectors can’t be used at all.
• Scope: Tenant-wide vs. Environment-specific. I set strict tenant-wide policies as a baseline, then create environment-specific overrides for developer environments that need more flexibility.
• Block the most common leakage paths first. I typically block personal email connectors (Gmail, Outlook Personal), social media, and consumer file storage (Dropbox, personal OneDrive) from business-tier connectors.
• Don’t over-block. Overly strict DLP kills adoption. If makers can’t do anything useful, they go around the platform, which is worse. Find the right balance.
• Test before deploying. A DLP policy can silently break existing flows. Use the DLP impact analysis tool in the Power Platform admin center before publishing.

21. What’s your approach to managing environments and licenses at enterprise scale?

This is a governance conversation as much as a technical one.

• Environment strategy. I recommend: Default environment (restricted, for personal productivity), Dev environments (per project or per developer), Test/UAT, Production. The Default environment is not for business apps — it has no isolation.
• Dataverse for Teams vs. Dataverse. Know the difference. Dataverse for Teams is included with M365 but has tight limits (2GB, Teams-only access). Full Dataverse requires Power Apps per-app or per-user licenses.
• License assignment. Per-user licenses make sense for power users building apps. Per-app licenses (now called “Pay-as-you-go” in some scenarios) make sense for broad user adoption of specific apps.
• Center of Excellence (CoE) Starter Kit. I always recommend deploying the CoE kit. It gives you visibility into all apps, flows, and connectors across your tenant, and flags things like apps with no owners, overly permissive flows, and orphaned resources.

22. How do you handle app versioning and rollback in Power Apps?

Power Apps has built-in version history. From the maker portal, you can restore any previous version of an app with two clicks. But for enterprise solutions, that’s not enough.

My approach:

• Store solutions in source control (Azure DevOps or GitHub). Use pac solution export and check in the unpacked solution files.
• Use solution versioning. Every time you promote to production, increment the solution version. This creates a clear audit trail.
• For rollback, I don’t rely on the “restore version” button in production. I re-import the previous managed solution from source control. This is controlled, trackable, and works for all components in the solution, not just the app.
• For Canvas Apps specifically, the version in the maker portal is app-level only — it doesn’t version your Dataverse schema changes. That’s why solution-level versioning is essential.

23. Explain how you use managed identities or service principals with Power Platform.

Service principals let you run flows and automated processes without tying them to a specific user account. This is critical for production — if the person who built the flow leaves, their account gets disabled, and everything breaks.

• Create an app registration in Azure AD
• Grant it the required Dataverse API permissions (user_impersonation for Dataverse)
• In Power Platform, go to admin center → Application Users → register the service principal
• Assign it a security role in the target environment
• Now flows can use the service principal for Dataverse connections instead of a user account

For SharePoint connections, this is more nuanced — SharePoint connectors in Power Automate still require a user account connection for most operations. Service principals work best for Dataverse-centric solutions.

Advanced Formulas & Patterns

24. What is the difference between Patch, SubmitForm, and UpdateContext — and when do you use each?

These are three different tools, and they’re often misused:

• UpdateContext — Updates local variables on the current screen only. Not for data sources. Use it for UI state: UpdateContext({showModal: true}).
• Patch — Writes data directly to a data source (SharePoint, Dataverse, SQL). Gives you surgical control — you specify exactly which columns to update. Use it when you’re not using a standard form, or when you need to patch multiple records in a loop.
• SubmitForm — Submits the data from a Form control to the data source. It’s the easiest approach when you have a Form control bound to a data source. It automatically handles new/edit mode and required field validation.

My rule: use SubmitForm when you have a form. Use Patch when you don’t, or when you need fine-grained control (like patching a subset of fields without a form).

25. How does ForAll work, and what are the common pitfalls with it?

ForAll iterates over a table and performs an action for each row. Think of it like a forEach loop.

Common pitfalls:

• ForAll is not delegable. It always processes the local table, not the server. If you’re running ForAll on a large SharePoint list, you’re only working with the delegated set of records.
• Order of execution isn’t guaranteed. ForAll may execute iterations in any order, and it can run them concurrently. Don’t write logic that assumes sequential execution.
• Use ForAll with Patch for bulk updates. This is the standard pattern to update multiple records at once: ForAll(MyCollection, Patch(MyList, LookUp(MyList, ID = ThisRecord.ID), {Status: "Approved"}))
• Avoid nested ForAll. It’s slow and hard to debug. Flatten your logic or use Power Automate for complex multi-step iteration.
• It doesn’t return values you can easily use. If you need the output of a ForAll, collect results into a collection with Collect.

26. How do you implement conditional navigation and deep linking in Power Apps?

• Conditional navigation. I used Navigate(ScreenName, ScreenTransition.Fade, {param1: value1}) to pass context between screens. The third parameter lets you set local context variables on the destination screen.
• Deep linking — you can pass parameters to a Canvas App via URL: ?tenantId=...&source=.... Inside the app, read them with Param("paramName"). This is useful for launching an app from SharePoint, Teams, or an email link and landing directly on a specific record.
• For model-driven apps, deep links follow a structured URL format that includes the environment ID, app ID, table name, and record ID. You can construct these programmatically.

27. What are named formulas (App.Formulas) and how are they different from global variables?

Named formulas are one of the newer and most underused Power Apps features.

A named formula is a formula you define once at the app level and reference anywhere, like a variable — except it’s not a variable. It’s a formula that recalculates automatically whenever its dependencies change.

// App.Formulas
TodayFormatted = Text(Today(), "[$-en-US]mmmm d, yyyy");
ActiveUsers = Filter(Users, IsActive = true);

Key differences from global variables:

• No assignment needed. You don’t call Set(). The formula just stays current.
• Lazy evaluation. It only computes when it’s accessed, not when the app starts.
• No OnStart dependency. This is huge — you can use named formulas to replace a lot of OnStart bloat, which improves app startup time.
• Immutable pattern. You can’t assign a new value to a named formula from a button. It’s reactive, not imperative.

Use named formulas for computed values you need globally — current user info, formatted dates, and filtered data sets that multiple screens use.

28. How do you build a reusable component library in Power Apps?

Component Libraries are separate Power Apps files that contain reusable components — custom controls built from standard controls.

How I approach it:

• Create a Component Library (separate from any app) in the maker portal
• Build components with custom input and output properties so they’re configurable
• Publish the library and import it into multiple apps
• When the library is updated and republished, all apps using it get a notification to update

Best practices:

• Keep components atomic — one component, one purpose
• Use input properties for all data inputs rather than hardcoding
• Expose output properties for values the app needs to read back (like a selected value from a custom dropdown)
• Don’t put connectors inside components — keep data access in the app, pass data into the component via properties

The biggest gotcha: component libraries don’t automatically push updates to apps. You have to explicitly update the library reference in each consuming app.

29. How do you approach testing in Power Apps?

Testing is an area where Power Apps has historically been weak, but it’s improving.

• Power Apps Test Studio — Built-in tool for Canvas Apps. You can record user interactions and create assertions. It integrates with Azure Pipelines for automated UI testing.
• Manual test plans. For most projects, I maintain a structured test matrix covering: happy path, edge cases, error states, permission levels, and device types.
• Monitor tool. Use the Power Apps Monitor during testing to trace all data calls, check for delegation issues, and spot performance problems.
• Unit test logic extracted to flows. If complex logic lives in a Power Automate flow, I test it independently with different inputs before wiring it to the app.
• Peer review of formulas. I treat complex Power Apps formulas the same way I treat code — they should be reviewed by another developer.

Test Studio is improving, but it’s not at the level of mature web testing frameworks yet. For critical enterprise apps, I complement it with manual testing and code-level checks in any PCF controls.

30. How do you handle multilingual/localization requirements in a Power Apps solution?

Localization in Power Apps isn’t built into the way you might hope, but here’s a pattern that works well:

• Create a Translations SharePoint list or Dataverse table with columns: Key, LanguageCode, TranslationValue
• On app load, collect the translations for the user’s language: ClearCollect(Translations, Filter(TranslationsTable, LanguageCode = userLang))
• Create a helper function (or named formula): GetText(key) = LookUp(Translations, Key = key, TranslationValue)
• Reference it on controls: Label.Text = GetText("WelcomeMessage")

For RTL language support (Arabic, Hebrew), Power Apps has RTL layout support built in — you set the layout direction at the app level. Test it early; RTL often breaks layout assumptions you’ve made.

AI & Modern Features

31. How are you incorporating Copilot and AI Builder into enterprise Power Apps solutions?

This is an area that’s moved fast in the last couple of years.

AI Builder gives you pre-built and custom AI models you can use inside Power Apps and Power Automate without writing any ML code:

• Form processing — extract data from PDFs, invoices, receipts
• Object detection — identify objects in images
• Text classification — categorize feedback, support tickets
• Sentiment analysis — understand customer feedback tone
• Custom prediction models — train a binary classification model on your Dataverse data

I’ve used Form Processing heavily for invoice automation — the app captures an invoice photo, AI Builder extracts the fields, and Power Automate creates the record in the finance system. It’s genuinely impressive for what it replaces.

Copilot in Power Apps (the end-user Copilot chat panel) lets users interact with your app using natural language. As a developer, you can enable it in canvas apps, and it can help users navigate, find records, and understand data. For enterprise rollouts, make sure your data is properly secured before enabling this — Copilot respects user permissions, but it’s worth auditing.

32. What’s the new Copilot Studio integration with Power Apps, and how does it differ from the built-in Copilot?

The built-in Copilot in Power Apps is a general-purpose assistant provided by Microsoft. You enable it, and it works with your app’s data sources.

Copilot Studio lets you build a custom AI agent — you control the knowledge base, the conversation flow, the escalation paths, and the personality. You can then embed that custom agent into a Canvas App or a Model-Driven App.

Use case distinction:

• Built-in Copilot → General Q&A and navigation within the app. Low effort to enable.
• Custom Copilot Studio agent → Tailored experience with specific knowledge (your company’s HR policy, your product catalogue, etc.), custom actions, and integration with your specific backend systems.

For enterprise solutions, I almost always build a custom agent when Copilot is required. The generic agent isn’t specific enough to be genuinely useful.

33. How do you use Power Fx’s ParseJSON function for dynamic API responses?

ParseJSON is one of the more powerful recent additions to Power Fx. It lets you work with dynamic JSON in Canvas Apps without knowing the schema upfront.

// Store an HTTP response or flow output
Set(apiResponse, ParseJSON(myFlow.Run().responseBody));

// Access properties
Set(userName, Text(apiResponse.user.name));
Set(itemCount, Value(apiResponse.data.count));

Key things to know:

• ParseJSON returns an untyped object. You must explicitly cast properties to the type you need: Text(), Value(), Boolean(), DateValue()
• Nested navigation uses dot notation: apiResponse.results.items
• For arrays, use ForAll(Table(apiResponse.items), ...) to iterate
• Error handling: wrap in IfError because if the JSON is malformed or a property doesn’t exist, it will error

This feature replaced many scenarios where people previously had to hack JSON apart with string functions. Use it.

34. How do you integrate Power Apps with Azure services beyond the standard connectors?

Standard connectors cover a lot, but for deep Azure integration, here’s what I use:

• Custom connector pointing to an Azure API Management gateway. APIM becomes a controlled, governed entry point to Azure services (Azure Functions, Logic Apps, Cosmos DB, etc.). The custom connector talks to APIM, and APIM routes to the right backend.
• Azure Functions via HTTP connector. For lightweight, serverless logic. Functions can do things Power Automate can’t — complex calculations, file processing, calling third-party libraries.
• Azure Service Bus / Event Hubs. Power Automate has Service Bus connectors. I use this for event-driven architectures where Power Apps submits work to a queue and Azure processes it asynchronously.
• Azure Blob Storage connector. For file management beyond what SharePoint document libraries offer — large files, binary data, and content delivery.
• Managed Identity for security. When Azure Functions or APIM needs to call back into Dataverse or SharePoint, use managed identities instead of storing credentials.

35. What are the key considerations when migrating a legacy application to Power Apps?

This comes up constantly in enterprise settings — migrating from an old Access database, a custom ASP.NET app, or a legacy InfoPath form.

Here’s my checklist:

• Data migration first, app second. Don’t build the Power App while the data model is still in flux. Migrate and validate the data in Dataverse (or your target store) before building screens.
• Don’t replicate the old UI. Legacy apps often have terrible UX that people have just gotten used to. Use the migration as an opportunity to rethink the workflow.
• Map permissions carefully. Legacy apps often have informal security (“everyone just knows not to edit that field”). You need to formalize this in Dataverse security roles or SharePoint permissions.
• Plan for the parallel running period. Users will need to use both the old and new system for some overlap period. Make sure data stays in sync during that window.
• Training and change management. Power Apps looks and feels very different from a desktop app. Budget time for training, not just technical delivery.
• Performance baseline. Know what “acceptable performance” means to the users before you build. Measure after.
• Consider what not to migrate. Some functionality in the old system nobody uses. Don’t bring dead features forward — confirm what’s actually needed.

36. How do you handle large binary file uploads (images, PDFs) in Power Apps?

The standard approach of storing files directly in SharePoint or Dataverse has size limits — Dataverse attachments cap at 128MB per file by default, and Canvas Apps have a 2MB data transfer limit per call.

Here’s what I do:

• For files under 2MB, use the Attachment control and patch directly to SharePoint or Dataverse
• For larger files, generate a SAS URL via an Azure Function and upload directly from the browser to Azure Blob Storage — bypassing the Power Apps data limit entirely
• Store only the Blob URL in Dataverse/SharePoint, not the file itself
• Use Power Automate to handle any post-upload processing (virus scanning, thumbnail generation, indexing)

37. What is the difference between Set and UpdateContext, and when does using the wrong one cause real bugs?

• Set creates or updates a global variable — accessible from any screen in the app
• UpdateContext creates or updates a local variable — only accessible on the current screen

The bug I’ve seen most often: a developer uses UpdateContext to store a selected record, then tries to read it on a different screen and gets nothing. Or worse — they use Set everywhere and pollute the global namespace with dozens of variables that are only relevant to one screen.

My rule: if the variable is only relevant to one screen, use UpdateContext. If multiple screens need it, use Set. And name your variables clearly — prefix globals with g_ and locals with l_ if your team is large.

38. How do you implement role-based UI in a Canvas App (showing/hiding controls based on user role)?

The clean pattern:

• On app start, look up the current user’s role: Set(g_userRole, LookUp(AppRoles, UserEmail = User().Email, Role))
• Use that variable to control visibility: Button.Visible = g_userRole = "Admin"
• For more complex multi-role scenarios, store the user’s roles as a collection and check with CountIf(g_userRoles, Role = "Admin") > 0

One thing to stress: hiding a control does not secure the data. A hidden button can still be tapped via workarounds, and hidden galleries still load data. Always back UI-level role control with proper Dataverse security roles or server-side filtering. UI role control is UX, not security.

39. How do you use Environment Variables in Power Apps solutions, and why do they matter?

Environment variables store configuration values (API endpoints, feature flags, SharePoint site URLs) that change between environments — dev, test, production.

Instead of hardcoding https://mycompany.sharepoint.com/sites/dev, you reference an environment variable. When you move the solution to production, you just update the variable’s value. No code changes, no broken connections.

Types supported: Text, Number, Boolean, JSON, Data Source, and Secret (stored in Azure Key Vault).

I use them for:

• SharePoint site URLs
• Azure Function endpoints
• Feature toggles (enable/disable experimental features per environment)
• API keys (pointing to Key Vault secrets, never plain text)

If you’re not using environment variables, you’re hardcoding — and hardcoding is a support ticket waiting to happen.

40. How does the Power Apps Monitor tool help you debug production issues?

Monitor is one of the most underused tools in Power Apps. It lets you trace everything happening in the app in real time:

• Network calls — see exactly what queries are going to SharePoint, Dataverse, or custom connectors, and what comes back
• Formula traces — see which formulas fired, in what order, and what they returned
• Error details — see actual error messages instead of the generic “Something went wrong”
• Delegation warnings live — see which calls are pulling less data than expected due to delegation

For production debugging, you can invite a user to a Monitor session remotely — they run the app normally, and you watch the trace. This is incredibly powerful for reproducing user-reported bugs.

You can also download the trace log and share it with Microsoft support for deeper issues.

41. What is the Dataverse Web API, and when would you use it directly instead of Power Apps connectors?

The Dataverse Web API is a RESTful OData endpoint that lets you interact with Dataverse data programmatically. It’s the underlying API that most connectors use.

I reach for it directly when:

• I’m building a PCF control that needs to query Dataverse without going through Power Apps formulas
• I’m writing an Azure Function or external service that integrates with Dataverse
• I need OData batch requests (multiple operations in a single HTTP call) for performance
• I need access to Dataverse operations the connector doesn’t expose (like executing custom actions or functions)

Authentication is via OAuth 2.0 with Azure AD. The base URL follows the pattern: https://{orgname}.api.crm.dynamics.com/api/data/v9.2/

42. How do you implement approvals in Power Apps beyond the basic Approvals connector?

The built-in Approvals connector in Power Automate is great for simple scenarios, but breaks down when you need:

• Multi-stage sequential approvals with conditional routing
• Parallel approvals (all approvers must approve)
• Delegation (approver is on leave, route to their manager)
• Full audit trail with comments and timestamps
• Custom approval UI instead of email/Teams cards

For enterprise approvals, I build a custom approval system:

• An Approvals table in Dataverse with columns: RecordID, ApproverEmail, Status, Comments, DueDate, Stage
• A Power Automate flow that creates approval records, notifies approvers, and advances stages based on outcomes
• A Canvas App or Model-Driven App form where approvers take action directly (faster than email links)
• A history table that logs every action for the audit trail

This is more work upfront, but gives you full control and a better user experience.

43. What are Power Pages, and how do they relate to Power Apps from an architecture standpoint?

Power Pages (formerly Power Apps Portals) is a low-code platform for building external-facing websites backed by Dataverse. Unlike Canvas or Model-Driven Apps, which require a Microsoft 365 or Power Apps license to access, Power Pages sites are accessible to anonymous or authenticated external users.

Where they fit architecturally:

• The data layer is Dataverse — same tables, same security model
• External users authenticate via Azure AD B2C, local accounts, or social identity providers
• Power Automate flows run in the background for business logic
• Liquid templating and JavaScript customize the front-end

I use Power Pages for: customer portals, vendor submission forms, partner onboarding sites — anywhere the audience is outside the organization. Think of it as the public-facing layer on top of your Dataverse backend.

44. How do you handle timezone issues in Power Apps and Dataverse?

Timezone handling is one of those things that look simple but aren’t.

Dataverse stores DateTime fields in UTC. When displaying them in Power Apps, the platform converts them to the user’s local time zone — but only for fields marked as User Local behavior. Fields with Date Only or Time Zone Independent behavior don’t convert.

Common issues:

• A date entered as “March 17” in India shows as “March 16” for a US user — because the UTC conversion crosses midnight
• Comparing dates in formulas using Today() can give wrong results if the user’s timezone isn’t accounted for

My approach:

• Use Date Only behavior for fields that represent a calendar date (birthdate, due date) where time doesn’t matter
• Use User Local for timestamps (created on, modified on, meeting start time)
• Use Time Zone Independent for fields that should always show the same value regardless of who’s viewing (a scheduled broadcast time, a global event)
• In formulas, use TimeZoneOffset() if you need to manually adjust times

45. How do you implement pagination in a Canvas App when working with large datasets?

Power Apps doesn’t have built-in server-side pagination UI — you have to build it. Here’s the pattern I use:

// Variables
Set(g_currentPage, 1);
Set(g_pageSize, 20);

// Current page data
ClearCollect(g_currentData,
    FirstN(
        LastN(AllData, CountRows(AllData) - (g_currentPage - 1) * g_pageSize),
        g_pageSize
    )
);

For large datasets where you can’t load everything at once, I use Power Automate to handle server-side pagination — the flow accepts a page number and size, queries Dataverse with $skip , and $top OData parameters return just that page.

Navigation buttons increment/decrement g_currentPage and trigger a data refresh. Show the user something like “Page 3 of 14” using Ceiling(CountRows(AllData) / g_pageSize).

46. What are canvas app containers, and how do they improve responsive design?

Containers are layout controls that hold other controls and automatically manage their positioning. There are two types:

• Horizontal container — arranges child controls side by side
• Vertical container — stacks child controls top to bottom

Before containers, responsive layout in Canvas Apps was painful — you had to manually set X, Y, Width, and Height formulas on every control relative to the screen size.

With containers:

• Set the container to fill available space
• Child controls stretch or shrink proportionally
• You get something approaching CSS flexbox behavior

My approach for responsive apps:

• Use a vertical container as the main layout wrapper
• Use horizontal containers inside it for row-level layouts
• Set Fill on the app to use containers everywhere
• Test on both mobile and tablet form factors throughout development, not just at the end

47. How do you use Power Apps with Microsoft Teams — and what are the deployment differences?

Power Apps apps can be surfaced in Teams in two ways:

1. Personal app — The Canvas App appears as a tab in the Teams left rail. Any canvas app can be pinned here. Good for individual productivity tools.
2. Tab in a channel or meeting — The app appears as a tab in a specific Teams channel or meeting. Good for team-level collaboration tools.

Deployment differences:

• Apps deployed through Teams don’t need users to go to make.powerapps.com — they access it entirely within Teams
• Dataverse for Teams environments (formerly Project Oakdale) are automatically created when you build an app in Teams. These are lighter environments with storage limits and Teams-only access.
• For full enterprise apps, build in a standard environment and surface it in Teams as a tab — don’t rely on the Dataverse for Teams environment for anything serious

One gotcha: the Teams app manifest needs to be configured correctly. If you’re deploying to the whole organization, use the Teams Admin Center to push it out organization-wide rather than have users install it manually.

48. How do you handle complex lookup filtering in Model-Driven Apps?

The standard lookup in a Model-Driven App shows all records from the related table. For most real-world scenarios, you need to filter that down — show only active accounts, or only contacts related to the current user’s business unit.

Three ways to filter lookups:

• View filtering — Change the default lookup view to one with a built-in filter. Simplest approach, no code needed.
• addCustomFilter (JavaScript) — Use the addCustomFilter method in a form’s OnLoad event to apply a dynamic FetchXML filter to the lookup at runtime. This is the most flexible option and what I use most.
• Filtered lookup using Power Fx (MDA) — In newer Model-Driven Apps with Power Fx enabled, you can write a filter expression directly in the lookup control’s filter property. No JavaScript needed.

Always test filtered lookups when switching between create and edit mode — filters sometimes behave differently depending on whether the parent record exists yet.

49. What is FetchXML, and when do you use it over OData queries?

FetchXML is Dataverse’s proprietary XML-based query language. It predates OData and is still extremely powerful for complex queries.

I use FetchXML over OData when:

• I need aggregate queries (sum, count, avg) that OData doesn’t handle cleanly
• I need linked entity queries (joins) across multiple tables with specific column selections
• I’m building Advanced Find views or custom reports in Model-Driven Apps
• I’m using the Dataverse connector in Power Automate with the “List rows” action and the query gets too complex for OData filter syntax

You can build FetchXML visually in Model-Driven Apps using Advanced Find, then download the XML and paste it into your Power Automate action or JavaScript code. The FetchXML builder is your best friend here — don’t write it from scratch.

50. How do you approach performance profiling of a slow Model-Driven App form?

A slow Model-Driven App form is usually caused by one or more of these:

• Too many JavaScript web resources loading. Audit which scripts run on OnLoad. Defer or remove scripts that aren’t needed on first render.
• Blocking synchronous operations. Any XMLHttpRequest in synchronous mode or heavy computation in OnLoad blocks the form. Move to async patterns.
• Too many subgrids. Each subgrid makes its own database call. If you have 6 subgrids on one form, that’s 6 extra queries on every form open. Reduce or lazy-load them.
• Plugins running on retrieve. Check if any server-side plugins run on the Record Retrieve message for that table. Poorly written plugins add seconds to every form load.
• Use the F12 Network tab + Performance profiler. Record a form load, identify the slowest operations, and work backwards.
• Power Platform Advisor. The CoE Toolkit’s Power Platform Advisor flags performance anti-patterns at the solution level.

51. How do you stay current with Power Platform changes — and how do you manage breaking changes in production?

This one matters more than people give it credit for, because Microsoft ships updates fast.

How I stay current:

• Release wave documentation — Microsoft publishes 2 release waves per year (Wave 1 and Wave 2). I read the release plan every time a new one drops.
• Power Apps blog and Tech Community forums — Real practitioners post workarounds, gotchas, and insights before they show up in official docs.
• Sandbox environment with updates enabled. I keep a non-production environment that gets updates before they roll out to production. Test everything there first.

Managing breaking changes:

• Enable managed environment update policies in the Power Platform Admin Center. This gives you some control over when updates hit your production environments.
• Monitor deprecation notices. Microsoft gives advance notice for deprecated features — usually 12 months. Don’t ignore these. I’ve seen teams scrambling to rewrite flows because they ignored a deprecation notice for 10 months.
• Regression testing after updates. Run your Test Studio test suite (or manual test checklist) after every major platform update. Even changes that shouldn’t affect your app sometimes do.

Also, you may like some more Power platform tutorials:

• Search a SharePoint List in Power Apps
• Power Apps Dropdown Show Only Unique Values
• Preferred Solution in Power Platform
• Set Dropdown Default Value to Blank in Power Apps

Wrapping Up

If you’ve worked through all 51 of these, you’ve covered the territory that genuinely matters in senior Power Apps interviews — not just what a feature is, but when to use it, when to avoid it, and what breaks in the real world.

The interviews that go well aren’t the ones where you recite definitions. They’re the ones where you can say “I’ve seen that go wrong in production, here’s what I do instead” — and back it up with specifics.

Architecture decisions, security design, ALM discipline, delegation gotchas, PCF lifecycle, Dataverse modeling, and AI integration — these are the areas where experienced developers separate themselves. Keep building, keep breaking things in dev, and keep reading the release notes. The platform moves fast, and staying current is half the job.

Good luck.

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

Later, when the project grew, and I started organizing components inside solutions, I realized something important: new components were not always being added to the solution I expected.

That’s when I discovered the Preferred Solution setting.

Once I started using it properly, managing apps, flows, and other components became much easier. Everything automatically went into the correct solution without extra manual steps.

In this tutorial, I’ll explain in simple terms:

• What a Preferred Solution is in Power Platform
• Why is it useful in Power Platform development
• How to set it up: Preferred Solution is in Power Platform

If you build Power Apps, Power Automate flows, Copilot Agent, or Dataverse components, understanding this setting can save you a lot of time.

What Is a Preferred Solution in Power Platform?

In Power Platform, a solution is basically a container where you store your components.

For example:

• Power Apps apps
• Power Automate flows
• Copilot Agents
• Dataverse tables
• Columns and relationships
• Environment variables
• Connection references

Instead of creating these components randomly in the environment, it’s best practice to create them inside a solution.

However, creating components inside a solution requires opening the solution first.

That’s where Preferred Solution comes in.

When you set a Preferred Solution, Power Platform will automatically add any new components you create into that solution.

So instead of manually adding them later, the platform does it for you.

Think of it like this:

Without Preferred Solution:

• You create a flow -> it goes to the default environment
• Later, you manually move it into a solution

With Preferred Solution:

• You create a flow -> it automatically goes into your selected solution

It removes extra steps and keeps your work organized.

Why the Preferred Solution Setting Is Important

When I started working on larger Power Platform projects, I realized that organization becomes very important.

Imagine this situation. You create:

• 10 Power Apps
• 20 flows
• 5 Agents
• several tables
• environment variables
• connection references

If these components are scattered across the environment, it becomes confusing very quickly. In this type of case, we can use a Preferred Solution to help avoid that.

Here are some benefits.

• Your work stays in the right place. You won’t accidentally create components in the default solution anymore. Everything lands where it belongs.
• Correct publisher prefix on every component. If your solution publisher prefix is “contoso_”, all your tables and columns will use that prefix automatically. No more “new_” prefix on things you forgot to build inside the solution.
• Easier exports and deployments. Since all your work is in one solution, exporting and deploying becomes much cleaner.
• Great for teams. Each maker on the team sets their own preferred solution, so their changes are automatically tracked in one place. You can see who built what.
• No need to navigate into the solution first. You can build from anywhere in the maker portal and trust that components will end up in the right solution.

Where You Can Find the Preferred Solution Setting

The Preferred Solution setting is available in the Power Apps Maker Portal. You can set it from your user settings.

The setting applies only to your account, not the entire environment. That means each developer can choose their own preferred solution. It does not affect other users.

How to Enable the Feature in Power Platform (Admin Step)

Now, Preferred Solution enables all the environments, but we need to enable “Create new canvas apps and cloud flows in Dataverse solutions”. This feature ensures that cloud flows and Power Apps are also stored in the preferred solution.

To do this, follow the steps below:

1. Go to the Power Platform Admin Center, click Manage, then Environments, and finally select your Environment.

2. Click on Settings, then expand Product and click Features.

3. Then search “Create new canvas apps, and cloud flows in Dataverse solutions” and enable Canvas apps and Cloud flows.

4. Click Save

How to Set Our Preferred Solution in Power Platform

Once the feature is enabled, here’s how each maker can set their own preferred solution:

1. Go to the Power Apps site. In the left-hand navigation, click Solutions.

2. You’ll see a banner or button that shows “Set preferred solution”.

3. Click any one of them. Then a dropdown will appear showing all the unmanaged solutions in your environment. In my case, I want the IT Help Desk solution to be the preferred solution. Then click on Apply.

4. You’ll now see a “Preferred solution” label next to that solution in the Solutions list. Check the screenshot below.

You can set a preferred solution where you already have an unmanaged solution. Also, you can set a preferred solution while creating the solution by checking the Set as your preferred solution check box.

Now every new component you create will automatically go into that solution.

Once the Preferred Solution is set, many components you create will automatically be stored inside it.

To test this, I created a Canvas app with one text label. Check the screenshot below.

After saving this app, I select my IT Help Desk Solution there, and I can see my app.

Components Are Automatically Added to the Preferred Solution

Once the Preferred Solution is set, most components created in the maker portal are automatically added to that solution. We saw one example in the above section.

Some common components include:

• Canvas apps
• Model-driven apps
• Cloud flows
• Dataverse tables
• Columns and relationships
• Copilot agents
• Environment variables
• Connection references
• AI Builder components

This means you do not need to manually open the solution before creating these components. Power Platform automatically places them in the preferred solution for you.

Components That Are Not Always Added Automatically

While the Preferred Solution setting works for most components, there are some situations where it may not apply.

For example:

• Components created directly from the solution editor
• Items created using legacy interfaces
• Some third-party connectors or integrations
• Components created through API or automation scripts

In these cases, you may still need to manually add the component to the solution.

Conclusion

The Preferred Solution setting is a small feature in Power Platform, but it makes a big difference in real projects. It ensures that all your apps, flows, and components are automatically stored in the correct solution.

If you regularly build Power Apps, Power Automate flows, or Copilot agents, I strongly recommend setting a preferred solution before starting development. It keeps your environment organized and makes deployment much easier.

You may also like:

• Power Apps Camera Control
• Power Apps Remove Function
• Create a SharePoint List View Using REST API in Power Automate
• Role-Based Security in Power Apps (With SharePoint Groups)
• Create a Horizontal Scrollable Gallery in Power Apps
• Send a Mobile Notification Using Power Automate

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

However, all the flows were created using that account, and the connections were linked to it. If the account was deleted, the flows would stop triggering or fail due to broken connections.

In Power Automate, flows are strongly dependent on the account and connections used during creation. Simply sharing the flow with another user does not automatically transfer ownership of the connections.

In this tutorial, I will show you, step by step, how to safely handle this situation by sharing the flow with another user and updating the connections. So the flow continues to work even after the original account is removed.

Create a Test User Account in the Microsoft 365 Admin Center

For this scenario, I created a test user account in the Microsoft 365 Admin Center. This account was used to build the Leave Management application and create all the Power Automate flows.

To create the test user:

1. Open the Microsoft 365 Admin Center.
2. Navigate to Users → Active users.
3. Click on Add a user.
4. Enter the required details such as display name, username, and domain.
5. Assign the necessary licenses (Power Apps and Power Automate).
6. Complete the setup process.

After creating the user account, I logged in using this test user and created the Cloud Flows for the application.

Create a Cloud Flow Using the Test Account

After creating the test user account, log in using that account and create a Cloud Flow.

Before creating the Cloud Flow, I first created a SharePoint list to store the Leave Management details.

The list contains the following columns:

• Employee Name (Single line of text)
• Leave Type (Choice)
• Start Date (Date and Time)
• End Date (Date and Time)

This SharePoint list will be used as the trigger source for the flow. Whenever a new item is created in this list, the Power Automate flow will trigger and send an email notification.

Follow the steps below to create the flow:

1. Sign in to Power Automate using the test user account. Click on Create from the left navigation menu. Select Automated cloud flow.

2. Enter a flow name (Leave Request Notification Flow). Choose the trigger: When an item is created (SharePoint). Click Create.

3. Then provide the following required parameters:
   • SharePoint Site Address
   • List Name (Leave Management)

4. Add the action Send an email (V2) from Outlook and provide the parameters below:
   • To: Employee Email
   • Subject: Your Leave Request (@{triggerBody()?[‘Title’]}) Submited Succesfully
   • Body:

Hi @{triggerBody()?['EmployeeName/DisplayName']},
Your Leave Request Submited Succesfully Below are the Detalis:
Leave Type: @{triggerBody()?['LeaveType/Value']}
Start Date: @{formatDateTime(triggerBody()?['StartDate'],'dd/mm/yyyy')}
End Date: @{formatDateTime(triggerBody()?['EndDate'],'dd/mm/yyyy')}
Thanks

Now save the flow and go to the sharepoint list and add a leave request. Then, after some time, you can see that the requested employee will get an email.

Now the flow is created using the test user account, and all the connections are linked to that account.

Share the Flow with Another User in Power Autoamte

After creating the Cloud Flow using the test account, the next step is to share the flow with another user. This ensures that another user can manage and modify the flow if needed.

Follow the steps below to share the flow:

1. Go to Power Automate and open My flows. Select the flow that was created using the test account.
2. Click on the Share option from the top menu.

3. Enter the name or email address of the second user. Assign the required permission (for example, Co-owner).

The second user now has access to the flow. However, it is important to understand that sharing the flow does not transfer the ownership of the existing connections. The connections are still associated with the original test user account.

Delete the Test User Account in the Microsoft 365 Admin Center

After sharing the flow with another user, delete the test user account from the Microsoft 365 Admin Center.

Follow the steps below:

1. Go to the Microsoft 365 Admin Center.
2. Navigate to Users → Active users.
3. Select the test user account that was used to create the flow.
4. Click on Delete user.
5. Confirm the deletion.

Once the account is deleted, try adding a new item to the SharePoint Leave Management list.

You will notice that the flow does not trigger. Even though the flow was shared with another user, the connections are still tied to the deleted account. As a result, the trigger and actions fail due to invalid or broken connections.

How to Fix the Broken Connections in Power Automate

After deleting the original test user account, the flow stops triggering because the connections are still associated with the deleted account. Even though the flow was shared, ownership of the connection was not automatically transferred.

To fix this issue, follow the steps below:

1. Sign in to Power Automate using the second user account (the co-owner). Go to My flows and open the shared flow.

2. You will notice that the trigger and actions show connection errors. Click on each trigger and action that has a broken connection.
3. Select Add new connection. Authenticate using the second user’s credentials.

4. Update all required connections (SharePoint, Outlook, etc.)

After updating the connections, add a new item to the SharePoint list again. Now, the flow will trigger successfully and work as expected.

In this tutorial, I explained what happens when a Power Automate flow is created using a test user account and that account is later deleted. I showed how the flow stops working because the connections are linked to the deleted account. I also showed that sharing the flow does not transfer ownership of the connection.

Finally, I explained how to fix the issue by updating the connections using another user account so that the flow continues to work properly.

You may like the following Power Automate tutorials:

• Add Rows to Excel in Power Automate
• Create an HTML Table in Power Automate
• Expense Reimbursement and Approval using Power Automate
• Create Calendar Events from a SharePoint list using Power Automate

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

However, the management team did not review these reports every month. Instead, they reviewed them quarterly. Because of this, at the end of every quarter, someone had to manually download all three monthly PDF reports, merge them into a single PDF file, and then send it to the management team.

The client asked us how we could automate this manual process.

After some research, I found that the Encodian connector provides an action called “Merge documents to PDF,” which allows us to merge multiple PDF files into one single file.

In this tutorial, I will show you how to merge PDF files in Power Automate using the Encodian “Merge documents to PDF” action.

Merge PDF Files in Power Automate

Here we have two PDF files stored in a folder in the SharePoint document library, as shown below. Now, I will create an instant cloud flow in Power Automate that merges these two PDF files into a single PDF and saves the merged file back to the same SharePoint document library folder.

Now, let’s see how to create a flow in Power Automate to merge PDF files using a third-party action. In this flow, we will use the Merge documents to PDF action from Encodian.

To use the Encodian action, you need an API key. Fill out and submit the form to generate an API key. Later, you can configure the Encodian action with the generated API key.

Now, follow the steps below to merge pdf files:

1. Go to the Power Automate site, click on + Create, and then select Instant cloud flow.

2. Now, provide the flow name and select Manually trigger a flow. Then click on Create.

3. Select the Get file content using path action. After that, provide the following details:
   • Site Address: Select or enter your SharePoint site address.
   • File Path: Provide the file path of the first PDF file.

4. Again, select the Get file content using path action. Then provide the information below:
   • Site address: Select or provide the site address.
   • File path: Provide the file path of the second PDF.

5. Now we will merge the two PDFs, so select the Merge documents to PDF action in Power Automate. Then provide the information below:
   • PDF filename: Provide the PDF file name
   • Filename: Provide the file name like below. As my file name is info1.pdf
   • File content: Provide the file content from dynamic content
   • Filename: Provide the file name like below. As my file name is info2.pdf
   • File content: Provide the file content from dynamic content

6. Then select Create file action and provide the following parameter:
   • Site address: Select or provide the SharePoint site address.
   • Folder Path: Select the folder path
   • File name: Provide the file name of the dynamic content
   • File content: Provide the file content of the dynamic content.

To run the flow, click on the Test icon, then select Manually and click on Test again. If prompted, configure the required connections, then click on Run flow. Once the flow runs successfully, click on Done.

Now you can see the flow ran successfully. Also, you can check in the SharePoint library that both the PDFs have been merged into a single PDF file.

This is how to merge pdf files using Power Automate flow. Also, you can merge more than 2 pdf files using this method.

You may like the following Power Automate tutorials:

• Add Rows to Excel in Power Automate
• Power Automate Flow Not Triggering After Owner Account Deleted
• Create an HTML Table in Power Automate
• Expense Reimbursement and Approval using Power Automate
• Create Calendar Events from a SharePoint list using Power Automate

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

After checking the flow settings, I found that the issue was related to connection references. The problem was that this was not a small flow. It had multiple approval levels, logging logic, and follow-up message steps. In such cases, changing the connection by opening each action inside the flow is time-consuming and risky.

Earlier, I used to think that the only way to fix this was to open the flow and change the connection action by action. But now, Power Automate provides an option to change the connection reference directly, without opening the flow in edit mode.

In this tutorial, I will explain how to change the connection reference in a Power Automate flow.

What is a Connection Reference?

A connection reference specifies which connection a flow should use for a connector, such as SharePoint, Outlook, or Office 365 Users. Instead of hard-coding a connection, Power Automate uses connection references so flows can be reused across environments.

Note:

The Connection references option is visible only when the flow is part of a Solution or when the flow is created in a Developer environment. If the flow is created outside a solution, this option will not be displayed in Power Automate.

Change Connection Reference in Power Automate

Follow the steps below to change the connection reference for a flow.

1. Go to Power Automate and click on My Flows or Solutions.
2. Open the flow for which you want to change the connection reference. In my case, I am using the Site Requests flow.

3. Once the flow is opened, you will see information such as the flow name, owner, status, and run history.

4. On the right side of the page, you will see a section called Connection references. This section lists all connectors used in the flow, such as:
   • SharePoint
   • Office 365 Users
   • Office 365 Outlook

5. Click on the connector you want to update. You can either select a different existing connection or configure it so that run-only users are prompted to provide their own connection for this connector. Save the changes.

This means any user who runs the flow will be asked to sign in with their own account for that connector. The flow will then run using their permissions.

This way, you can change the Connection Reference in Power Automate Flow.

Conclusion

In this post, I explained how to change the connection reference in a Power Automate flow. I showed where to find the connection reference option and explained the important requirement that the flow must be part of a solution or a developer environment.

You may also like:

• Create Custom Responses in Power Automate Approvals
• Remove User From SharePoint Group Using Power Automate
• Send Approvals in Microsoft Teams Using Power Automate
• Send Approval to SharePoint Group Members Using Power Automate
• Create an Approval Workflow in Power Automate Using Microsoft Forms

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

To meet this requirement, I used Power Automate to build a flow that detects a meeting invite in Outlook and automatically forwards it to the required recipients.

In this article, I will explain how to forward an Outlook meeting invite using Power Automate.

Create A New Event In Outlook

For this scenario, I first created a meeting in Outlook Calendar, which will later be forwarded automatically using Power Automate.

In the screenshot above, you can see that I created a new calendar event with the following details:

• Meeting Title: Power Platform Training
• Attendees: Patti Fernandez and Miriam Graham
• Meeting Type: Microsoft Teams meeting
• Schedule: Recurring every Monday from 22:00 to 22:25
• Start Date: January 6, 2026
• End Date: April 14, 2026

This meeting is created as a recurring event, which is important because in real client scenarios, meetings often repeat weekly or monthly.

Once this meeting is created, Outlook sends a meeting invite to the selected attendees.
In the next step, we will use Power Automate to detect this meeting invite and automatically forward it to another user or group without any manual action.

Forward an Outlook Meeting Invite Using Power Automate

Here, I will create an Instant cloud flow that allows users to enter the meeting title (subject) and the email address of the person to whom they want to send the meeting invite. Power Automate will then find the meeting in Outlook and forward it to the specified email address.

To do this, follow the steps below:

1. Go to Power Automate. Click Create from the left menu. Select Instant cloud flow. Select Instant cloud flow. Enter a flow name (for example: Forward Outlook Meeting Invite). Choose the trigger “Manually trigger a flow.” Click Create.

2. In the Manually trigger a flow action, click Add an input. Select Text. Name it Meeting Subject (this is the meeting title). Click Add an input again. Select Text. Name it Recipient Email Address.

Now, we need to get the meeting details from Outlook based on the meeting subject provided by the user.

3. Then add the Get events (V4) action to get the meeting ID and provide the following parameters:
   • Calendar id: Calendar
   • Filter Query: subject eq ‘@{triggerBody()?[‘text’]}’
   • Top Count: 1

This action finds the meeting from the Outlook calendar whose subject matches the value entered when the flow is triggered. Since we are setting Top Count = 1, Power Automate returns only the first matching meeting.

The Get events (V4) action returns the meeting details as an array. To forward the meeting, we need the Meeting ID.

4. Next, add a compose action and provide the following expression:

first(body('Get_events_(V4)')?['value'])?['id']

This expression extracts the ID of the first meeting returned by the Get events (V4) action.

5. Select the Compose action, navigate to the Settings tab, expand Get events (V4), and enable the Has failed option so the action runs only when Get events (V4) fails.

5. Then add a Condition action to check if the compose action has a value or not.

@{outputs('Compose')} is not equal to null

Now that we have the Meeting ID, we can forward the meeting invite using Microsoft Graph.

6. In the True section, add a Send an HTTP request action from the Office 365 Outlook connector and provide the following parameters:
   • URI:

https://graph.microsoft.com/v1.0/me/events/@{outputs('Compose')}/forward

7. Fill in the action parameters as shown below:
   • Method: Post
   • Body:

{
  "ToRecipients":[
      {
        "EmailAddress": {
          "Address":"@{triggerBody()?['text_1']}",
          "Name":""
        }
      }
     ],
  "Comment": "I hope you can make this meeting."
}

8. Inside the False section of the Condition, add Send an email (V2) action. Now provide the following parameters:
   • To: triggerOutputs()?[‘headers’]?[‘x-ms-user-email’]
   • Subject: Meeting Not Found
   • Body:

The meeting with the subject "@{triggerBody()?['text']}" was not found in the Outlook calendar.

Please check the meeting title and try again.

Test the Flow to Forward an Outlook Meeting Invite Using Power Automate

Finally, save and test the flow by providing:

• A valid meeting subject
• A recipient email address

If the meeting exists, the invite will be forwarded automatically.

Otherwise, the user will receive an email indicating that the meeting was not found.

Conclusion

In this tutorial, I showed how to forward an Outlook meeting invite using Power Automate. We created an instant cloud flow, searched for a meeting using the subject, extracted the meeting ID, and forwarded the invite to another user. I also explained how to handle cases when the meeting is not found and notify the user by email.

You may also like:

• Create Custom Responses in Power Automate Approvals
• Change Connection Reference in Power Automate Flow
• Remove User From SharePoint Group Using Power Automate
• Send Approvals in Microsoft Teams Using Power Automate
• Send Approval to SharePoint Group Members Using Power Automate
• Create an Approval Workflow in Power Automate Using Microsoft Forms

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com

But after the site is created, I need a way to remove that user from the SharePoint group, as they do not need access to the site.

In this blog post, I will show you how to remove user from a SharePoint group using Power Automate.

Remove User From SharePoint Group Using Power Automate

For this example, I am using the DMS SharePoint site and want to remove the user “Miriam Graham” from the Owners group.

Before I explain the steps, I want to show you how to get the Group ID. We will use this Group ID in the Power Automate flow to remove the user from the SharePoint group.

Get SharePoint Group ID using Power Automate

Now follow the steps below:

1. Open Power Automate and create an Instant Cloud Flow. Choose “Manually trigger a flow” as the trigger.

2. Next, add a “Send an HTTP request to SharePoint” action to get the Group ID, and provide the parameters shown below:
   • Site Address: Select your site address
   • Method: Get
   • Uri: _api/web/siteGroups/getByName(‘<groupName>’)?$select=Id
   • Headers:

{
  "accept": "application/json;odata=verbose"
}

When you run the flow, you will see the Group ID.

Note:

Make sure you have permission for that site to check the Group ID. Otherwise, the flow will return an “unauthorized” error.

This is how you can get the Group ID dynamically in Power Automate. But if you want to get it manually, go to the SharePoint group, and you can see the Group ID in the URL.

Remove User From SharePoint Group

Now I will show how to remove a user from a SharePoint group using Power Automate.

Follow the steps below:

1. In the above flow, add another “Send an HTTP request to SharePoint” action to remove the user, and provide the parameters shown below:
   • Site Address: Select your site address
   • Method: Get
   • Uri: _api/web/sitegroups/GetById(<group-id>)/users/getbyemail(‘<user-email>’)
   • Headers:

{
  "accept": "application/json;odata=verbose",
  "content-type": "application/json;odata=verbose",
  "X-HTTP-Method": "DELETE"
}

Now save the flow and run it manually. After the flow runs successfully, you will see that the member is removed from the SharePoint group.

If you face an error like “unauthorized,” it means you do not have permission to remove the user from the group.

In this post, we learned how to remove a user from a SharePoint group using Power Automate. First, we saw how to get the Group ID, and then we used that Group ID in another HTTP request to remove the user from the group.

If you face any errors or know any other way to do this, feel free to share it in the comments.

You may also like:

• Power Automate save email attachment to SharePoint
• Get Tenant Name in Power Automate
• Delete all files in a SharePoint folder using Power Automate
• Copy List Items To Another List In SharePoint Using Power Automate

Bijay Kumar

Hey! I’m Bijay Kumar, founder of SPGuides.com and a Microsoft Business Applications MVP (Power Automate, Power Apps). I launched this site in 2020 because I truly enjoy working with SharePoint, Power Platform, and SharePoint Framework (SPFx), and wanted to share that passion through step-by-step tutorials, guides, and training videos. My mission is to help you learn these technologies so you can utilize SharePoint, enhance productivity, and potentially build business solutions along the way.

www.enjoysharepoint.com