Whenever users submitted an expense claim, they had to manually enter all invoice details, such as:

• Vendor name
• Invoice date
• Tax amount
• Total amount
• Bank details
• Invoice line items

Even though all these details were already available inside the invoice PDF or image, users still had to type everything manually. This process was time-consuming and sometimes led to typing errors or incorrect data entry.

The client wanted a smarter solution.

They asked:

“Can users simply upload the invoice and let the system automatically fill most of the fields?”

That is when I built this Invoice Processing solution using Power Apps, Power Automate, AI Builder, and SharePoint.

In this solution, the user uploads an invoice file, such as a PDF or image, then clicks the Process Invoice button. Power Automate automatically extracts the invoice details using AI Builder and sends the extracted data back to Power Apps.

The best part is that users no longer need to manually enter all invoice details. Most of the fields are automatically populated from the uploaded invoice. Users can simply review the extracted information, make changes if needed, and then save the final data into SharePoint lists.

This not only improves the user experience but also reduces manual effort and helps prevent data entry errors.

Business Requirement

The main requirement is:

A user should be able to upload an invoice file in Power Apps. The invoice can be a PDF, JPG, JPEG, PNG, or GIF file. After clicking the Process Invoice button, Power Automate should extract all invoice details using AI Builder and return them to Power Apps.

The user should then be able to:

• View extracted invoice fields
• Modify extracted values if needed
• Add or edit invoice line items
• Save the final data into SharePoint

Another important aspect of this solution is that the entire application is built with a responsive layout in Power Apps. I used responsive containers, dynamic width and height formulas, and flexible layouts so that the application works properly across desktop, tablet, and mobile devices.

SharePoint Lists Used in This Solution

For this solution, I created two SharePoint lists:

1. Extracted Invoice Data
2. Invoice Items

1. Extracted Invoice Data SharePoint List

This is the main SharePoint list where invoice header-level details are stored.

The Title column can store the invoice number or a generated invoice reference number.

2. Invoice Items SharePoint List

This list stores the line item details extracted from the invoice.

The Title column can be used to store the invoice number or invoice reference ID, so that each item can be connected with the main invoice record.

Create a Power Automate Flow to Extract Data from PDF Invoices

To extract invoice details from the uploaded PDF or image, I created a Power Automate flow. This flow is triggered from Power Apps when the user clicks the Process Invoice button.

In this tutorial, I am not going to explain the complete step-by-step process for creating the AI Builder invoice extraction flow, because I have already explained that in detail in this article:

Extract Data from PDF Invoices Automatically Using Power Automate

In this solution, the flow contains three main actions:

When Power Apps calls a flow (V2)
        ↓
Run a prompt
        ↓
Respond to a Power App or flow

The uploaded invoice file is passed from Power Apps to Power Automate. Then, the Run a prompt action reads the invoice content and extracts key details, including the invoice date, vendor name, subtotal, tax amount, total amount, bank details, and line items.

Finally, the extracted values are returned back to Power Apps using the Respond to a Power App or flow action. Once the response is received, all extracted invoice fields are displayed in Power Apps, allowing the user to review and modify them before saving the data to SharePoint.

Build the Power Apps Extracted Invoice Data

After creating the Power Automate flow, I created a Power Apps screen where users can upload the invoice file.

In this screen, I used an Attachment control. This control allows users to select and upload an invoice file from their system. In this application, the user can upload only one invoice file at a time.

The uploaded file can be:

• PDF
• JPG
• JPEG
• PNG
• GIF

Once the invoice is selected, the file name is displayed inside the attachment control. In my example, I uploaded a PDF invoice named INV-2026-001.pdf.

I also added two buttons:

• Clear
• Process an Invoice

The Clear button is used to remove the selected invoice from the attachment control.

Reset(attachInvoice)

The Process an Invoice button is used to call the Power Automate flow. This button sends the uploaded invoice file to the flow, where the invoice details are extracted and returned back to Power Apps.

This is the Power FX code where I am calling the Power Automate flow:

Set(
            varExtractedData,
            invoiceProcess.Run(
                {
                    file: {
                        name: First(attach.Attachments).Name,
                        contentBytes: First(attach.Attachments).Value
                    }
                }
            )
        );

In this solution, the attachment control is mainly used to pass the uploaded invoice file from Power Apps to Power Automate for invoice extraction.

After processing the invoice, the extracted data is displayed on the Extracted Invoice Data screen.

On this screen, I used a Form control to display the main invoice details. These fields are automatically populated from the uploaded invoice file, such as invoice number, invoice date, due date, vendor details, customer details, subtotal, tax amount, total amount, currency, and bank information.

Below the form, I added an Invoice Items section. For this, I used a repeating table concept in a gallery to display the invoice line items extracted from the invoice. Each row contains the item description, quantity or hours, rate, and amount.

The user can review the extracted data and make changes if required. If the invoice has an extra item, the user can click the plus (+) icon to add a new row. If any item is not required, the user can remove it using the delete icon.

Finally, I added two buttons at the bottom of the screen:

• Submit: Saves the invoice header data into the Extracted Invoice Data SharePoint list and saves the invoice line items into the Invoice Items SharePoint list.
• Clear: Clears the current invoice data and resets the screen for a new invoice.

This is the Submit button Power FX code:

SubmitForm(Form3_2);

ForAll(
    galItems_2.AllItems,
    Patch(
        'Invoice Items',
        Defaults('Invoice Items'),
        {
            Title: First(colInvoiceData).Title,
            Name: txtName.Text,
            Quantity: Value(numQty.Value),
            Rate: Value(numRate.Value),
            Amount: Value(numAmount.Value)
        }
    )
);

Notify(
    "Your Order Has Been Submitted Successfully",
    NotificationType.Success
);
Clear(colInvoiceData);Clear(colInvoiceItems);
Navigate('Attachment Uplode Screen',ScreenTransition.Cover);

Test the Application

After completing the Power Apps screen and the Power Automate flow, the next step is to test the entire invoice-processing application.

First, upload an invoice file using the attachment control. In this solution, the application supports PDF and image files such as JPG, JPEG, PNG, and GIF.

After selecting the invoice file, click the Process an Invoice button. This button calls the Power Automate flow and sends the uploaded invoice file for processing.

Users can also remove the selected invoice file using the Clear button before processing another invoice.

In this application, only supported invoice file types can be uploaded, such as PDF, JPG, JPEG, PNG, and GIF.

If the user selects an unsupported file type, such as a Word document (.docx), the application displays a notification that the selected file type is not supported.

Once the flow runs successfully, AI Builder extracts the invoice details and returns the response to Power Apps. Then, all extracted invoice fields are automatically populated on the screen.

The user can then:

• Review the extracted invoice details
• Modify incorrect values if required
• Add additional invoice items
• Remove unnecessary invoice items

After verifying the information, click the Submit button to save the data in the SharePoint lists.

The invoice header information is stored in the Extracted Invoice Data list, and all invoice line items are stored in the Invoice Items list.

This way, we can extract the invoice data in Power Automate, modify it in Power Apps, and then store it in a SharePoint list.

Conclusion

In this tutorial, we learned how to build an invoice processing application using Power Apps, Power Automate, AI Builder, and SharePoint.

The user uploads an invoice file from Power Apps, Power Automate extracts the invoice data using AI Builder, and the extracted values are returned to Power Apps. The user can review, edit, and finally submit the invoice data. Once submitted, the invoice header details are saved into the Extracted Invoice Data SharePoint list, and invoice line items are saved into the Invoice Items SharePoint list.

Also, you may like some more Power Automate tutorials:

• Power Automate Multilevel Approvals
• Extract SharePoint Site Owner Email Using Power Automate
• Power Automate Send seven or 14-Day Task Due Reminder Emails
• Expense Reimbursement and Approval using Power Automate
• Create Multiple Sites in SharePoint Online using Power Automate from Excel
• Create SharePoint Online List and Columns from Excel 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

It’s one of those decisions that feels simple on the surface but can seriously affect how your app performs, scales, and behaves six months down the road. Pick the wrong one early, and you’re either rewriting everything or stuck with an app that crawls to a halt when your data grows.

I’ve worked with both, and in this tutorial, I’m going to walk you through the real differences — not just a boring feature comparison, but the practical stuff that actually matters when you’re building.

What Is a SharePoint List, Really?

A SharePoint list is essentially a table you can create inside a SharePoint site. Think of it like an Excel table that lives in the cloud. It has rows and columns, people can view and edit it directly in SharePoint, and you can connect to it from Power Apps without needing any extra licensing.

It’s been around for over 20 years, which tells you something — it’s reliable, familiar, and deeply woven into the Microsoft 365 world. Most people in your organization probably already know what SharePoint is. That’s a big deal when you’re trying to get adoption for a new app.

Here’s what a SharePoint list gives you out of the box:

• Columns for text, numbers, dates, choices, people, lookups, and more
• Built-in views and filtering directly in SharePoint
• Version history and basic item-level permissions
• Tight integration with Power Automate for simple workflows
• No extra licensing — it comes with almost every Microsoft 365 plan

What Is Dataverse?

Dataverse is Microsoft’s cloud-based relational database, and it’s the native data platform for the entire Power Platform. It’s built on top of Azure SQL, which means it behaves more like a proper database than a list.

When you use Dataverse, you’re working with tables (not lists), and those tables can have real relationships between them — one-to-many, many-to-many, the works. You can also build model-driven apps in Power Apps, which is something you simply can’t do with a SharePoint list.

Here’s what Dataverse brings to the table (pun intended):

• True relational data model with table relationships
• Row-level and column-level security (much more granular than SharePoint)
• Business rules and calculated columns built right into the data layer
• Full delegation support, so large datasets don’t break your app
• Audit logging and change history at the data level
• Supports both Canvas Apps and Model-Driven Apps
• Deep integration with Dynamics 365, Power BI, and AI Builder

The catch? You need a Power Apps Premium licence to use it in production. More on that in a moment.

The Big Differences That Actually Matter

Let me break down the areas where these two really diverge in practice.

The 5,000-Item Problem (Delegation)

This is the one that bites almost everyone who starts with SharePoint lists and then grows their app.

Power Apps has a concept called delegation. When your app filters or searches data, it ideally sends that query to the data source (server-side), and the data source returns only the matching records. That’s efficient.

But when you use a function or a column type that SharePoint doesn’t support in a delegated way, Power Apps has to download a chunk of records locally and then filter them on your device. And here’s the problem — it only pulls a maximum of 2,000 records by default (you can bump this to 2,000 in the settings, but not beyond).

So if your SharePoint list has 10,000 rows and you’re searching on a column that isn’t delegable, you’re only ever searching through the first 2,000. Your users will get wrong results and won’t even know it. That’s the kind of bug that’s really embarrassing to explain.

Dataverse handles delegation far better. Most filter and search operations are fully delegable, which means it can process millions of records server-side without ever hitting a local limit. If your data is going to grow, this alone is a massive reason to consider Dataverse.

Data Relationships

SharePoint lists don’t have real relationships. Yes, you can add a Lookup column that points to another list, but it’s very limited — you can only pull one column from the related list, and it doesn’t support cascading deletes, referential integrity, or anything resembling a proper foreign key.

Dataverse supports one-to-many and many-to-many relationships natively. You can look up related records across tables, enforce referential integrity, and use rollup and calculated columns that aggregate data from related tables automatically. If your app has anything more complex than a flat list — say, orders that have multiple line items, or employees that belong to departments — Dataverse gives you the tools to model that properly.

Security

This is where SharePoint’s approach starts to feel a little basic when compared to Dataverse.

SharePoint security works at the site level, list level, and item level. You can share a list with a group of people or lock down individual items, but the configuration gets complicated quickly, and there’s no easy way to say “this user can read all records, but only edit their own.”

Dataverse uses role-based access control (RBAC). You create security roles, assign them to users or teams, and define permissions at a very granular level — per table, per operation (create, read, update, delete), and even per column. You can hide an entire column from certain users without any custom code. For anything business-critical, this kind of control is invaluable.

Performance at Scale

SharePoint lists technically support up to 30 million items, but performance starts to degrade noticeably beyond around 100,000 records — especially in Power Apps. You’ll need to carefully manage indexed columns and view thresholds, and even then, some operations just get slow.

Dataverse is purpose-built for enterprise-scale workloads. It handles millions of rows without breaking a sweat, with optimised querying and no arbitrary thresholds to work around.

App Types You Can Build

Here’s something a lot of people miss. If you want to build a Model-Driven App in Power Apps, you must use Dataverse. SharePoint lists aren’t supported for model-driven apps at all.

Canvas Apps work with both. So if you’re happy building canvas apps (which are perfectly capable for most business needs), you have the flexibility to choose either. But if you ever want to use the model-driven experience — which gives you a lot of UI structure for free — Dataverse is your only option.

Side-by-Side: The Key Differences

So, When Should You Use SharePoint Lists?

Honestly, SharePoint lists are great for a lot of real-world scenarios. Don’t let anyone talk you out of them just because Dataverse sounds fancier.

Use a SharePoint list when:

• You’re building a simple departmental app — a leave tracker, an equipment request form, a visitor log
• Your data is unlikely to grow beyond a few thousand rows
• Your users already manage data in SharePoint and need direct access to it outside the app
• Cost is a constraint and you don’t have Premium licences
• You need to build something quickly and get it into people’s hands fast
• The app is tied to document management or SharePoint site content

I’d say the majority of small-to-medium business apps I’ve seen built by teams without dedicated developers are SharePoint-backed, and they work absolutely fine for their purpose.

And When Should You Use Dataverse?

Reach for Dataverse when the requirements start to outgrow what a list can handle.

Use Dataverse when:

• Your app will have more than 10,000–20,000 records and users need to filter and search across all of them
• You need relationships between multiple tables (e.g., projects → tasks → team members)
• The data is business-critical and you need proper audit trails and granular security
• You’re building for multiple user roles with different access levels
• You need to build a model-driven app
• You’re already using Dynamics 365, which means Dataverse is already part of your environment
• You want clean Application Lifecycle Management — moving your app and its data structure between dev, test, and production environments
• You need offline functionality for mobile users in the field

What About Licensing? Let’s Be Honest

This is the part that makes a lot of people hesitate on Dataverse, and fair enough.

SharePoint lists work with any standard Microsoft 365 licence. If your users have Microsoft 365 Business Basic, they’re good to go.

Dataverse requires a Power Apps Premium licence for every user who interacts with the app in production. As of 2025, that’s $20 per user per month (or $12/user/month at enterprise volumes of 2,000+ seats). There’s also a free Developer Plan if you just want to learn and build — it gives you 2 GB of Dataverse storage and full access to all features, but it’s for individual development use only, not production deployment.

The licence cost is real, and it’s worth factoring in before you commit. But if you’re building something that your organisation genuinely relies on — a business-critical process, something that handles sensitive data, or something that’s going to be used by hundreds of people — the extra cost per user is usually easy to justify.

A quick rule of thumb I use: if the broken app would cause a real business problem, invest in Dataverse. If the broken app would just be inconvenient, SharePoint list is probably fine.

My Recommendation for Getting Started

If you’re new to Power Apps and just getting your feet wet, start with a SharePoint list. The learning curve is gentler, there’s no extra cost, and you can build something useful in a day. Get comfortable with Power Apps as a tool before you add database concepts into the mix.

Once you start bumping into the limitations — delegation warnings, data getting stale, relationships getting messy — that’s your signal to look at Dataverse. And when you make the move, you’ll appreciate having a solid understanding of Power Apps already under your belt, because you’ll be able to focus on the data modelling rather than fighting the tool.

The two platforms aren’t really competitors. They’re different tools for different stages and different needs. Most mature Power Platform teams use both — SharePoint for quick wins and lightweight apps, Dataverse for anything that needs to scale or carry real business weight.

One Last Practical Tip

Before you build anything, ask yourself three questions:

1. How many records will this app have in 12 months? If the honest answer is “I have no idea, it could be a lot,” lean towards Dataverse.
2. Who needs to access what? If different users need different views of the same data with different permissions, Dataverse security is worth every penny.
3. Does this data relate to other data? If yes and you need that relationship to be reliable and queryable, don’t try to fake it with lookup columns in SharePoint.

Those three questions will point you in the right direction almost every time.

Also, you may like some more Power Apps and Dataverse tutorials:

• Dataflow in Dataverse
• Power Apps Image Control
• Power Apps Dataverse Yes/No Field
• Create Dataverse File Field
• Set Autonumber for Primary Name Column in Dataverse

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

In this SharePoint tutorial, I’ll walk you through multiple ways to check permissions — from the simplest point-and-click method to using PowerShell for a more detailed view. Let’s get into it.

What Are SharePoint Permissions, Anyway?

Before we jump into the how-to part, let me quickly explain what SharePoint permissions actually are — just so we’re on the same page.

Permissions in SharePoint control what a user can do on a site, library, list, or even a single file. They’re organized into permission levels, and each level bundles together a set of actions:

• Full Control – The user can do everything, including managing settings and adding/removing people. This is what site owners typically have.
• Edit – Users can add, edit, and delete items in lists and libraries.
• Contribute – Similar to Edit, but slightly more restricted. Users can add or update items, but can’t delete entire libraries.
• Read – View-only access. Users can look at content and download files, but can’t change anything.
• View Only – Like Read, but users can’t even download files. They can only preview content in the browser.

These permission levels are then assigned to users or groups, which is how SharePoint controls who can do what.

Now, SharePoint Online uses three default groups out of the box:

• Owners – Full Control
• Members – Edit
• Visitors – Read

For Team Sites connected to Microsoft 365 Groups, permissions are also managed through the Microsoft 365 Group itself — so someone added to the Group automatically gets site access. Communication Sites, on the other hand, use the classic Owners/Members/Visitors model only.

Check Site Permissions in SharePoint Online

Here, I will show you five methods for checking site permissions in SharePoint Online.

Method 1: Check Site Permissions from the Site Settings Panel in Sharepoint

This is the quickest way to get an overview of who has access to your site. You don’t need any admin tools — just site owner access.

Steps:

1. Open the SharePoint site you want to check.
2. Click the gear icon (⚙) in the top-right corner.
3. Select Site permissions from the dropdown.

A panel will slide out on the right side of your screen. Here you’ll see:

• The three default groups: Owners, Members, and Visitors
• How many people are in each group
• Any sharing links that are active

You can click on any group to see exactly who’s in it. This gives you a quick snapshot — great when you just need to confirm someone is in the right group.

When to use this: Perfect for a quick, high-level check. If you just want to see who has access and what group they’re in, this is your go-to.

Method 2: Use “Check Permissions” to Look Up a Specific User in SharePoint

This method is a lifesaver when someone says, “I can’t access the site,” and you need to quickly check their permissions. Instead of scrolling through a list of users, you just type their name and get a direct answer.

Here’s how to do it:

1. Open the SharePoint site.
2. Click the gear icon (⚙) → Site permissions.
3. In the permissions panel, scroll down and click Advanced permissions settings. (This opens a classic-style page — don’t be alarmed, that’s normal.)
4. In the ribbon at the top of the page, click Check Permissions.
5. A small pop-up will appear. Type the name or email address of the user or group you want to check.
6. Click Check Now.

SharePoint will instantly show you:

• What permission level does that person have on the site
• Whether they have access through a SharePoint group or a direct assignment
• Whether the permission is inherited or unique

Example: Let’s say your colleague Sarah says she can’t edit a document. You go to Check Permissions, type in Sarah’s name, and the result shows she’s in the Visitors group — which is Read-only. That’s your answer. You just move her to the Members group and she’s good to go.

This is probably the most useful built-in tool for day-to-day troubleshooting.

Method 3: Check Permissions on a Specific Library, List, or File in SharePoint Online

Sometimes you don’t want to check site-level permissions — you want to see who has access to a specific document library, folder, or even a single file. This is especially useful when unique (broken) permissions have been applied at the item level.

For a Document Library or List:

1. Go to the library or list.
2. Click the gear icon (⚙) → Library settings (or List settings).
3. Under Permissions and Management, click Permissions for this document library.
4. You’ll see a list of all users and groups with their permission levels on that specific library.

For a Specific File or Folder:

1. Hover over the file or folder.
2. Click the three dots (…) → Details.
3. In the details pane, click Manage access.
4. You’ll see who has access, what kind of access they have, and any sharing links.

This is where it gets interesting — if you see a notice that says “This library has unique permissions”, it means it’s no longer inheriting permissions from the site. It has its own permission rules. That’s important to know, especially for security audits.

Method 4: View Group Memberships in SharePoint Online

Another angle to look at this is checking what users belong to which SharePoint group. This helps when you want to audit group memberships rather than checking individual users.

1. Go to Gear icon → Site permissions → Advanced permissions settings.
2. You’ll see all the groups listed (Owners, Members, Visitors, and any custom groups).
3. Click on any group name to see all its members.

From inside the group page, you can also go to Settings → View Group Permissions to see exactly what permission level the group has on each site or subsite.

Pro tip: If your Team Site is connected to a Microsoft 365 Group (which most modern Team Sites are), some users might have site access through the Group rather than a SharePoint group directly. Go to Gear icon → Site permissions and look for the “Group membership” section at the top of the panel to see those users.

Method 5: Check Permissions Using PowerShell (PnP PowerShell)

If you need to audit permissions across a whole site or export results to a spreadsheet, the manual methods above won’t cut it. That’s where PowerShell comes in.

I’ll show you the PnP PowerShell approach — it’s the cleanest and most modern way to work with SharePoint Online programmatically.

First, make sure you have PnP PowerShell installed. If you don’t:

Install-Module PnP.PowerShell

Connect to your SharePoint site:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/your-site" -Interactive

Get all permissions for the site:

Get-PnPPrincipalPermission | Select PrincipalId, PrincipalType, RoleName, Scope

This gives you a list of all users and groups, along with their role names (like Full Control, Edit, Read) and the scope they apply to.

Filter by a specific user or group:

Get-PnPPrincipalPermission | Where-Object { $_.Principal.Title -like "*John Smith*" } | Select PrincipalId, PrincipalType, RoleName, Scope

Just replace John Smith with the name you’re looking for.

Export the results to a CSV file:

Get-PnPPrincipalPermission | Select PrincipalId, PrincipalType, RoleName, Scope | Export-Csv -Path "C:\Permissions_Report.csv" -NoTypeInformation

This gives you a spreadsheet you can share with managers or keep as an audit record. Very handy.

When to use PowerShell: When you’re dealing with a large site, need to audit multiple users at once, or want a documented record of who has access to what.

SharePoint Inherited vs. Unique Permissions — And Why It Matters

One thing that trips people up is the concept of inherited vs. unique permissions.

By default, everything in SharePoint inherits permissions from the level above it:

• A library inherits from the site
• A folder inherits from the library
• A file inherits from the folder

When you break that inheritance and set custom permissions on a library, folder, or file — those are called unique permissions.

Why does this matter? Because if someone has access to the site, they might not have access to a specific library if that library has unique permissions that exclude them. This is a common reason why people say “I can see the site, but I can’t find a specific document.”

When you’re checking permissions and something doesn’t add up, always check whether the library or item has unique permissions — that’s usually where the answer is hiding.

Common Scenarios and Quick Fixes

Here are a few real-world situations you’ll probably run into:

“A user says they don’t have access to the site”
→ Go to Check Permissions (Method 2), type their name, and see what comes up. If nothing shows, they haven’t been added at all. If it shows Read, they might be in the Visitors group when they need to be in Members.

“A user can access the site but not a specific library”
→ Check if that library has unique permissions (Method 3). If it does, the user might not be listed there even though they’re on the site.

“You want to see a full list of everyone with access before offboarding a project”
→ Use PowerShell (Method 5) to export a full permissions report.

“A guest user says they can’t access the site”
→ Check at both the site level and the specific content level. Also confirm that external sharing is enabled on the site and at the tenant level in the SharePoint Admin Center.

A Few Things to Keep in Mind

• You need to be a Site Owner (or have Full Control) to check permissions on a site. If you’re just a Member, you won’t see the Check Permissions option.
• For Team Sites connected to Microsoft 365 Groups, some access is managed through the Group — not directly in SharePoint. Always check both.
• For Channel Sites in Teams, permissions are managed entirely through Teams and appear as read-only in SharePoint. Don’t try to change them from the SharePoint side.
• Nested security groups (groups inside groups) can cause performance issues and sometimes make permission auditing harder. It’s worth simplifying these when you get the chance.

You may also like:

• Set Column Default Value in SharePoint Library
• Give SharePoint Library Upload Access to External Users
• Restrict User Access to Specific Document Libraries in SharePoint

Checking site permissions in SharePoint Online doesn’t have to be confusing. Once you know the right tools to use — the Site Permissions panel for a quick overview, Check Permissions for individual users, and PowerShell for bulk auditing — you’ll be able to troubleshoot access issues in minutes rather than hours.

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

In this tutorial, I’ll walk you through every realistic search scenario — from basic text search to date ranges, Choice fields, Person fields, and large lists — with the exact formulas you need and the reasoning behind each one.

Power Apps Search() vs Filter() — Which One Do You Actually Need?

This is the question I get most often, and the answer is almost always the same: it depends on your column type. Here’s the quick rule I follow:

Use Search() when:

• You’re searching only Single Line of Text columns
• Your list has fewer than 2,000 items
• You want a simple, minimal formula

Use Filter() when:

• You’re working with Choice, Date, Number, or Person columns
• Your list is large (and you’re using indexed columns)
• You need complex AND/OR logic

Here’s a side-by-side comparison to make the decision easier:

If you pick the wrong one for your column type, Power Apps either throws a delegation warning or silently returns no results, and that silent failure is the worst kind.

Decision Tree: Which Formula Should I Use in Power Apps?

Use this to quickly decide your approach before writing a single line:

What column type are you searching?
│
├─ Single Line of Text only?
│   └─ Use Search() 
│
├─ Choice column?
│   └─ Use Filter() + AddColumns() + .Value 
│
├─ Date column?
│   └─ Use Filter() + DateAdd() 
│
├─ Person / People Picker column?
│   └─ Use Filter() + .DisplayName 
│
└─ Mix of Text + Choice / Person?
    └─ Use Filter() + AddColumns() + OR operator

Bookmark this. It saves a lot of trial and error.

Power Apps Setting Up: Connect Your SharePoint List

Before any of the formulas below work, make sure your SharePoint list is connected. In Power Apps Studio:

1. Go to Data (left panel) → click + Add data
2. Search for SharePoint → select your site → pick your list
3. Add a Text input control (rename it to something like txtSearch)
4. Add a Gallery control and connect it to your SharePoint list

That’s your base setup. Now let’s get into the actual scenarios.

Search a SharePoint List in Power Apps

Now let’s work with some real examples on how to search a SharePoint list in Power Apps.

Scenario 1: Search Multiple Text Columns at Once in Power Apps

Real-world use case: An HR team wants a single search box to find employees by name, department, or location in an Employee Onboarding list.

I have a SharePoint list called Employee Onboarding with these columns:

• Title (Employee Name) — Single line of text
• EmployeeLastName — Single line of text
• Department — Choice field
• Location — Choice field

Approach 1: Using Power Apps Filter() with a Collection (Best for Mixed Column Types)

First, load the list into a Power Apps Collection on the screen’s OnVisible property:

Collect(colEmployeeList, 'Employee Onboarding')

Then set the Gallery’s Items property to:

Items = Filter(
    colEmployeeList,
    txtSearch.Text in Title ||
    txtSearch.Text in Department.Value ||
    txtSearch.Text in Location.Value
)

Why Department.Value and Location.Value? Because Choice fields in SharePoint are objects, not plain text strings. You need .Value to extract the actual text. Forget this, and your formula either errors out or returns nothing.

Approach 2: Using Power Apps Search() for Text-Only Columns

If you’re only searching text columns and your list is under 2,000 rows, this is simpler:

Items = Search(colEmployeeList, txtSearch.Text, Title, EmployeeLastName)

Column names in Power Apps Search() must be in quotes. It won’t accept Choice, Number, or Person columns here; those need the Filter() approach above.

Scenario 2: Search by Date Field in Power Apps

Real-world use case: A procurement team wants to filter purchase orders by sale date.

I have a SharePoint list called Book Purchase Info with a “Sale Date” column and a date picker control named dtSelectDate.

Filter by a Specific Selected Date in Power Apps

Items = Filter(
    'Book Purchase Info',
    'Sales Date' >= dtSelectDate.SelectedDate,
    'Sales Date' < DateAdd(dtSelectDate.SelectedDate, 1, TimeUnit.Days)
)

The DateAdd(..., 1, Days) part is important — it makes the filter inclusive of the entire selected day, not just midnight.

Filter by Today’s Date in Power Apps

Items = Filter(
    'Book Purchase Info',
    'Sales Date' >= Today(),
    'Sales Date' < DateAdd(Today(), 1, TimeUnit.Days)
)

It shows all records with a Sales Date from today’s start of day (start of the day) until before tomorrow, so you will see only today’s sales records.

Filter by a Date Range (Start and End Date) in Power Apps

Use two date pickers: dtStartDate and dtEndDate.

Items = Filter(
    'Book Purchase Info',
    ('Sales Date' >= dtStartDate.SelectedDate Or IsBlank(dtStartDate.SelectedDate))
    And
    ('Sales Date' < DateAdd(dtEndDate.SelectedDate, 1, TimeUnit.Days) Or IsBlank(dtEndDate.SelectedDate))
)

The IsBlank() wrappers make both date pickers optional — if a user only sets a start date, the Power Apps gallery still works. I always add these in production apps.

Show All Records in Power Apps When No Date Is Selected

Items = Filter(
    'Book Purchase Info',
    (
        'Sales Date' >= dtDate.SelectedDate
        And 'Sales Date' < DateAdd(dtDate.SelectedDate, 1, TimeUnit.Days)
    )
    Or IsBlank(dtDate.SelectedDate)
)

Set the date picker’s IsEditable property to true. So users can clear the date and see all records again.

Scenario 3: Search a Choice Column in Power Apps

Real-world use case: A manager wants to filter a Products list by Status (Submitted, Approved, Rejected, Pending).

My Products list has a Status Choice column. Here’s the formula for the gallery:

Items = Filter(
    AddColumns(Products, ChoiceValue, Status.Value),
    txtSearch.Text in ChoiceValue
)

Power Apps AddColumns() creates a temporary text version of the Choice field called ChoiceValue. Without this, you can’t use in or Search() on a Choice column at all.

Also, update the gallery label’s Text property:

Text = ThisItem.ChoiceValue

Search Text Columns AND a Choice Column Together

Items = Sort(
    Search(
        AddColumns(Products, "ChoiceValue", Status.Value),
        txtSearch.Text,
        "Title", "CustomerName", "ChoiceValue"
    ),
    'Sales Date',
    Ascending
)

This lets users type a product name, a customer name, or a status value — all in one search box. This is one of my most-used patterns in client apps.

Scenario 4: Search by Person / People Picker Column in Power Apps

This is the single most common cause of the “Wrong column type” error I see. Search() cannot read Person fields because they’re objects, not text strings. Always use Filter() with .DisplayName.

Real-world use case: A library app needs to filter books by the author or uploader.

Search a Person Field with a Text Input in Power Apps

Items = Filter(
    'TSInfo Attachments',
    txtSearch.Text in 'Book Author'.DisplayName
)

Search the “Created By” Field in Power Apps

Items = Search(
    AddColumns(Products, CreatedByUser, 'Created By'.DisplayName),
    txtSearch.Text,
    CreatedByUser, Title, CustomerName
)

And in the gallery label: Text = ThisItem.CreatedByUser

Let Users Pick a Person From a Dropdown in Power Apps

Set the Power Apps Combo Box’s Items property to:

Items = Choices(Products.'Created By')

Set both DisplayFields and SearchFields on the Combo Box to ["DisplayName"].

Then filter the gallery:

Items = Filter(
    Products,
    'Created By'.DisplayName in ComboBox1.Selected.DisplayName
)

Scenario 5: Search Distinct / Unique Values in Power Apps

Real-world use case: You want a dropdown that shows only unique departments — no duplicates.

Power Apps: Distinct Values from Text Columns

Items = Distinct(Products, Title)

Power Apps: Distinct Values From a Choice Column

Items = Distinct(Products, Status.Value)

Filter Power Apps Gallery: Show Unique Employee Names by Department

Items = Distinct(
    Filter('Employee Onboarding', Department.Value = Dropdown1.Selected.Value),
    Title
).Result

Note the .Result at the end — that’s required when using Distinct() as a gallery source.

Scenario 6: Searching Large SharePoint Lists

If your list has more than 2,000 items, Search() will silently stop returning all results. This catches many people off guard.

Here’s what actually works for large lists:

• Use Power Apps Filter() with indexed columns. In SharePoint, go to your list → List Settings → Indexed Columns → add the column you’re filtering on.
• Use ClearCollect at app start for lists under ~5,000 rows, then filter against the collection. This avoids repeated server calls.
• Avoid AddColumns() on large datasets directly from SharePoint — it forces a full load and breaks delegation.
• Set Data Row Limit to 2,000 in Power Apps Settings → App Settings → General → Data row limit. This is the maximum Power Apps allows for non-delegable operations.

ClearCollect(colMyList, 'Your SharePoint List')

Then filter colMyList rather than the SharePoint data source directly. Yes, this means a slightly longer load time at app start — but it’s far more reliable for search.

Troubleshooting: Power Apps Search Not Working

Run through this checklist before anything else:

•  Using Search() on a Choice column? → Switch to Filter() + AddColumns() + .Value
•  Using Search() on a Person column? → Switch to Filter() + .DisplayName
•  Getting a delegation warning? → Your list likely has more than 2,000 rows. Add column indexing or use a ClearCollect pattern
•  Search returns nothing when text box is empty? → Wrap your formula with If(IsBlank(txtSearch.Text), YourList, Filter(...))
•  “Column does not exist” error? → Your column has special characters in its internal SharePoint name. Use ClearCollect(colTest, YourList) then inspect column names in View → Collections
•  Search works in preview, but not after publishing? → Check if the app has the correct SharePoint site permissions for all users, not just the owner

The most common issue by far is the column type mismatch — someone using Search() on a Person or Choice field. That single mistake is behind 80% of the “my search isn’t working” questions I see in community forums.

Quick Reference: Delegation & Limits

Summary Table: Formula Patterns by Column Type

Also, you may like:

• Display Power Apps Gallery Distinct Values
• Parse JSON in Power Apps
• Power Apps Sort Distinct Filter
• Power Apps Dropdown Show Only Unique Values
• Power Apps First Function
• Set Combo Box Value On Button Click in Power Apps

Frequently Asked Questions

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

In this tutorial, I’ll walk you through SharePoint Document Set vs Folder, exactly what each one does, how they compare, when to use which, and how to set up document sets step by step.

What Is a SharePoint Folder?

A folder in SharePoint works just like a folder on your desktop. You create it, drag files in, and use it to keep things organized. It’s simple, familiar, and requires zero configuration.

Most teams default to folders because they’re intuitive. Everyone knows what a folder is. You don’t need training to use one.

But here’s the problem — folders break down fast once your document library grows.

The real limitations of SharePoint folders:

• Metadata doesn’t apply at the folder level. If you want to tag documents by department, project name, or status, you have to do it file by file.
• Filters in SharePoint views only work within the folder you’re currently in — not across the whole library. So if you’re looking for all “Draft” documents across five folders, good luck.
• Deep folder hierarchies become a navigation nightmare. Users end up clicking through four or five levels just to find one file.
• You can’t associate a workflow with an entire folder. Automation applies to individual files, not the container.

Folders are great for small, simple scenarios — say, a team of three people sharing a handful of files. But for anything complex, they quickly become a liability.

Check out Get SharePoint Folder Permissions Using PowerShell

What Is a SharePoint Document Set?

A document set in SharePoint is essentially a supercharged folder. Technically speaking, it’s a special content type in SharePoint that lets you group related documents together and treat them as a single unit.

Here’s what makes it different from a folder:

• You can apply shared metadata at the document set level, and that metadata flows down to every document inside it automatically.
• It has its own welcome page — a customizable landing page you can use to display key properties, links, and instructions for anyone opening it.
• You can kick off a workflow on the entire document set, not just individual files.
• Version history is tracked at the set level, so you can see how the entire collection evolved over time.
• You can pre-load document templates into a document set, so every time someone creates a new one, the right starter documents are already there.

Think of it this way: a folder is a plain cardboard box. A document set is a labeled binder with dividers, a cover page, and a tracking sheet attached to the front.

A Real-World Example to Understand Folders Vs SharePoint Document Sets

Let me give you a concrete scenario. Say your legal team manages client contracts. Each contract involves multiple documents: the draft agreement, the signed PDF, the supporting compliance forms, and the renewal notice.

With folders, you’d create a folder called “Client A – Contract 2026” and dump all those files in. If someone later asks, “Show me all contracts that expire in Q2,” you’re stuck manually opening folders one by one.

With a document set, you create one document set for each contract. You attach metadata fields to it — client name, contract value, expiry date, status. Now you can build a filtered view in your library that shows every contract expiring in Q2, sorted by value. You can trigger a Power Automate flow to send reminders before the renewal date. And every document inside inherits the client name automatically — no manual tagging needed.

That’s the difference. Folders organize. Document sets manage.

Check out SharePoint Folder Structure Best Practices

Feature Comparison

Check out Create Choice Column With Fill-in Options in SharePoint Document Library

Comparing Features of SharePoint Folders and Document Sets

Metadata and Content Types

One of the key advantages of document sets in SharePoint is their ability to share common metadata. When you create a document set, you can assign shared metadata, which is automatically applied to all documents within the set. This ensures consistency and makes it easier to search and retrieve content.

SharePoint Folders, in contrast, cannot share metadata across contained documents. Each file within a folder can have its own metadata, but there’s no simple way to enforce consistency without manually updating each item.

Versioning and Workflows

Document sets in SharePoint support versioning for the entire set, meaning you can track and restore changes to the entire collection of documents as a single unit. This is particularly useful when multiple documents are part of a larger process or project.

Folders in SharePoint do not have this capability; versioning in folders applies to individual files rather than the folder as a whole. Workflows can be associated with document sets, allowing for more complex business processes to be automated and applied to the entire set.

Navigation and User Experience

Document sets provide a more streamlined user experience, as they display all the documents in a set within a single view. This can be customized to show important metadata and provide quick access to the documents’ content.

With folders, navigation can become more complex, especially with deep folder hierarchies. Users may have to click through multiple levels to find the documents they need, which can be time-consuming.

When Should You Use a Folder in SharePoint?

Folders still have their place. I’d recommend sticking with folders when:

• You’re organizing a small number of files without any metadata requirements
• Your team is not technically inclined and needs the simplest possible structure
• You just need quick, temporary grouping with no automation or reporting needs
• You’re managing files that don’t belong to any repeatable business process

For example, a team storing meeting agendas and notes for a one-off project can get away with a folder. No need to overcomplicate it.

Check out Delete Files From SharePoint Document Library Using Rest API in Power Automate

When Should You Use a SharePoint Document Set?

Go with document sets when:

• You’re managing a repeating type of work — like contracts, cases, projects, or campaigns — where the same set of documents gets produced each time
• You need consistent metadata applied across all documents in the group
• You want to trigger an automated workflow on the whole group — such as sending an approval request or a reminder email
• You need to filter and report on the entire group as one unit (e.g., “Show all open cases assigned to John”)
• Your team works with regulatory or compliance documents that need to be versioned and audited together

Some common real-world use cases I’ve seen document sets used for:

• Legal firms: One document set per client case, with all pleadings, evidence, and correspondence inside
• HR teams: One document set per employee onboarding, with contracts, ID verification, and training records
• Project teams: One document set per project phase, with specs, plans, and sign-off sheets
• Insurance companies: One document set per claim, with forms, photos, and assessment reports

Read Create Folders and Subfolders in SharePoint document library

How to Set Up Document Sets in SharePoint (Step by Step)

Before you can use document sets, you need to activate the feature at the site collection level. Here’s exactly how to do it.

Step 1: Activate the Document Sets Feature

1. Open your SharePoint site
2. Click the Settings gear icon (top right) → select Site Settings
3. Under Site Collection Administration, click Site collection features
4. Scroll to find Document Sets and click Activate

Here is a screenshot for your reference:

That’s it for activation. Now the content type becomes available across the site collection.

Step 2: Enable Content Types on Your Library

1. Open the document library where you want to use document sets
2. Click Settings → Library settings
3. Under General Settings, click Advanced settings
4. Under the Content Types section, select Yes to allow management of content types
5. Click OK to save. You can see the screenshot for your reference.

Step 3: Add the Document Set Content Type

1. Back in Library settings, scroll down to the Content Types section
2. Click Add from existing site content types like below screenshot:

3. In the dropdown, select Document Set Content Types from the “Select site content types from” list
4. Select Document Set and click Add, then click OK. Here is a screenshot for your reference.

Step 4: Create a Document Set

1. Open the document library
2. Click New in the command bar — you should now see Document Set as an option

3. Click it, give the document set a Name and Description, then click Save.

Your document set now appears in the SharePoint document library. Click on it to see the welcome page, where you can view all its properties, edit metadata, and start adding documents. You can see the screenshot below:

Step 5: Add Documents to the Set

Inside the document set, you can:

• Click Upload to add existing files
• Click New to create a new document from a template
• Drag and drop files directly into it

Any metadata you’ve assigned at the document set level (like project name or status) will be automatically applied to all files you add.

The Welcome Page

The document set welcome page is very useful. You can customize it to display key metadata fields, a list of documents in the set, links to related resources, and instructions for your team.

For example, if you’re using document sets for onboarding, the welcome page for each new hire’s document set could show their name, start date, department, status, and a checklist of what still needs to be uploaded. It becomes a self-contained hub for that specific record.

To customize the welcome page, open the document set, click Edit (or in classic view, click Edit Welcome Page), and customize it using web parts just like any other SharePoint page.

Check out Download File From SharePoint Document Library in Power Apps

Can You Use Folders Inside a Document Set?

Yes, you can create folders inside a document set for further organization. This works well when a document set has a large volume of files that need subcategories — like separating “Legal Documents” from “Financial Documents” within the same project set.

That said, use this sparingly. If you find yourself building deep nested structures inside document sets, it might be a sign that the metadata isn’t being fully utilized. A well-tagged flat structure is almost always easier to search and filter than a folder tree.

For Modern SharePoint

Document sets work in both classic and modern SharePoint. In modern SharePoint Online, the welcome page is built on the modern page framework, so it looks clean and responsive.

One thing to watch: in modern SharePoint, filters in views work much better with metadata than with folders. If you’re on SharePoint Online and struggling with filtering across folders, document sets with metadata columns are the better long-term architecture. The modern experience is built around metadata-first navigation.

Conclusion

So there you have it — folders and document sets both have their place in SharePoint, but they solve different problems.

If you’re managing a small set of files with no real structure needed, a folder gets the job done. But if you’re dealing with recurring work — contracts, projects, HR records, legal cases — document sets are genuinely worth the extra setup time. The ability to share metadata, trigger workflows, and filter across your entire library as a unit changes how your team works with documents.

I’ve seen teams stick with folders out of habit, then spend hours hunting for files or manually re-tagging documents. Once they switch to document sets for the right use cases, they wonder why they waited so long.

Start small — pick one repeating process in your team, set up a document set for it, and see how it feels. Once it clicks, you’ll naturally start applying it everywhere it makes sense.

If you’re still unsure which to use, run through this quick checklist:

Use a Folder if:

• Simple grouping with no metadata needed
• Small team, small number of files
• No automation or reporting required

Use a Document Set if:

• You manage a repeating type of work (projects, contracts, cases)
• You need shared metadata across related documents
• You want filtering, views, or workflows on the group
• Compliance or audit trail matters

If you have any questions or run into issues setting it up, drop a comment below — I’m happy to help!

You may also like:

• Restrict User Access to Specific Document Libraries in SharePoint
• Give SharePoint Library Upload Access to External Users
• How to Set Column Default Value in SharePoint Library?

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

In this tutorial, I’ll walk you through every method to create a folder in SharePoint — in a document library, inside a list, creating nested (sub) folders, doing it through Microsoft Teams, and even how to enable or disable the folder option when it’s missing. Let’s get into it.

Before jumping in, just check these two things:

• Permissions: You need at least Contribute access to the document library or list where you want to create folders. If you’re a visitor (read-only), you won’t see the option.
• Folder command enabled: By default, the folder option is turned on in document libraries. But sometimes, admins disable it. I’ll show you how to re-enable it later in this tutorial.

Method 1: Create a Folder in SharePoint Online (Modern Experience)

This is the most common scenario — you’re using SharePoint Online (part of Microsoft 365), and you want to add a folder to a document library.

Here’s how to do it:

1. Go to your SharePoint site and open the document library where you want the folder. For example, let’s say it’s a library called Marketing Policies.
2. Click the + Create or upload button at the top right of the SharePoint document library.
3. From the dropdown, select Folder. You can refer to the screenshot below:

4. A small dialog box appears. Type a Folder Name — something descriptive like International Marketing or Q1 Reports.
5. You’ll also notice a Folder color option (it defaults to yellow). This is a nice visual touch if you want to color-code your folders — totally optional.
6. Click Create. Here is the screenshot for your reference:

That’s it. Your folder shows up right there in the library. Click on it to open it, and you’re ready to start uploading files into it.

Here is how to the SharePoint document library looks with some folders.

Quick tip: SharePoint Online allows up to 30 million files and folders in a single document library. So don’t worry about running out of space anytime soon.

Method 2: Create a Folder in SharePoint Classic Experience

If your organization is still using the SharePoint Classic interface (you’ll know because it looks a bit older and has a ribbon toolbar at the top), the steps are slightly different.

1. Navigate to your SharePoint site and open the document library.
2. Click on the Files tab in the ribbon toolbar at the top.
3. In the New group, click New Folder.
4. Enter a name for your folder in the Name field.
5. Click Create.

Done. The folder appears in your library just like in the modern experience.

Check out Create Choice Column With Fill-in Options in SharePoint Document Library

Method 3: Create a Subfolder (Nested Folder)

Sometimes a single level of folders isn’t enough. Maybe you have a Projects folder and you need separate subfolders for each project — like 2025 Projects > Project Alpha, Project Beta, and so on. SharePoint handles nested folders just fine.

Here’s how to create a subfolder:

1. Open your document library and click into the parent folder where you want to create the subfolder. Make sure you’re inside that folder — look at the breadcrumb trail at the top to confirm your location.
2. Once you’re inside the parent folder, click + New → Folder.
3. Give the subfolder a name and click Create.

Here is a screenshot for your reference.

The breadcrumb navigation is your friend here. It shows you exactly where you are in the folder hierarchy, so you don’t accidentally create a folder at the wrong level.

You can nest folders inside folders as deep as you need — though from experience, going more than 3–4 levels deep can make navigation confusing for your team. Keep it manageable.

Read Get SharePoint Document Library Size using PnP PowerShell

Method 4: Create a Folder in a SharePoint List

Most people don’t realize you can also create folders inside a SharePoint list, not just a document library. This is useful when you have a large list and want to group items by category or project.

The catch: folder creation in lists is disabled by default. You need to turn it on first.

Step 1 — Enable folder creation in a list:

1. Open your SharePoint list.
2. Click the Gear (Settings) icon → List settings.
3. Click Advanced settings.
4. Scroll down to the Folders section.
5. Under Make “New Folder” command available, select Yes.
6. Click OK.

Step 2 — Create the folder:

1. Go back to your list.
2. Click + New → Folder.
3. Enter a folder name and click Create.

The folder will now appear in your list, and you can move list items into it to group them.

Method 5: Create a Folder in SharePoint via Microsoft Teams

If your team mainly works inside Microsoft Teams, you don’t actually need to open SharePoint separately. Since Teams channels are backed by SharePoint document libraries, any folder you create in Teams shows up in SharePoint too — and vice versa.

Here’s how to do it directly from Teams:

1. Open Microsoft Teams and go to the channel where you want to add a folder.
2. Click on the Shared tab at the top of the channel.
3. Click + New → Folder (or look for the New Folder button depending on your Teams version).
4. Enter the folder name and click Create. Here is a screenshot for your reference.

The folder instantly appears in both Teams and the connected SharePoint document library. This is handy if your team lives in Teams and doesn’t want to jump into SharePoint separately.

How to Rename, Move, or Delete a Folder

Once you’ve created a folder, managing it is straightforward. Here’s a quick rundown:

• Rename a folder: Hover over the folder, click the three dots (…) that appear, and select Rename.
• Move a folder: Select the folder (click the checkbox next to it), then click Move to from the top toolbar. Pick the destination library or folder.
• Delete a folder: Hover over it, click the three dots, and select Delete. Deleted folders go to the Recycle Bin, so you can restore them within 93 days if needed.
• Share a folder: Click the three dots → Share, and you can invite people to access just that folder with specific permissions.

Check out Delete Files From SharePoint Document Library Using Rest API in Power Automate

How to Enable or Disable the Folder Option in a Document Library

Sometimes you’ll click + New and not see the Folder option. That means it’s been disabled at the library level. Here’s how to turn it back on (you need to be a site owner or have design permissions):

1. Open the document library.
2. Click the Gear (Settings) icon at the top right.
3. Select Library settings → More library settings.

4. Click Advanced settings.
5. Scroll down to the Folders section.
6. Under Make “New Folder” command available, select Yes.
7. Click OK. Here is a screenshot for your reference.

Go back to the library and the Folder option will be back in the + New menu.

To disable it (if you want to prevent users from creating folders), follow the same steps and select No instead.

Check out Create Folders and Subfolders in SharePoint document library using SPFx

Should You Use Folders or Views in SharePoint?

This is a fair question to ask. Folders work great when you want a simple, familiar file-explorer-style structure. But SharePoint also gives you something more powerful — metadata views. Here’s a quick comparison:

My honest take: for most teams, a combination works best. Use a light folder structure for top-level organization, and set up views with filters for day-to-day browsing. You don’t have to choose one or the other.

Check out Get SharePoint Document Library Folder Path in Power Automate

Best Practices for Naming and Organizing Folders in SharePoint

A few things I’ve learned that save a lot of headaches later:

• Keep folder names short and clear — “HR Policies 2026” is better than “All HR-Related Policy Documents for the Year 2025.”
• Avoid special characters in folder names — things like # % & * : < > ? / can cause issues, especially when syncing with OneDrive.
• Don’t go deeper than 3–4 folder levels — it gets hard to navigate and the file path can get too long for Windows sync.
• Use consistent naming conventions — if you name one folder “Q1-2026”, don’t name another “2026 Q2”. Pick a format and stick with it across your team.
• Review folder permissions occasionally — especially for sensitive folders. Folder-level permissions can be set in SharePoint, but they add complexity, so use them sparingly.
• Combine folders with metadata where possible — even inside a folder, adding columns like Department or Status makes finding files much faster.

Conclusion

Creating folders in SharePoint is genuinely simple once you know where to look. Whether you’re using the modern interface, the classic experience, Microsoft Teams, or working inside a list — the process takes less than a minute. The bigger skill is organizing those folders in a way that makes sense for your team long-term.

Start with a simple structure, keep folder names clean, and don’t nest too deep. That alone will make your SharePoint library a place people actually want to use instead of avoid.

You may also like:

• How to check if a file exists in the SharePoint document library in Power Automate?
• SPFx Upload File to SharePoint Document Library With Metadata
• Give SharePoint Library Upload Access to External Users
• How to Set Column Default Value in SharePoint Library?

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

In this tutorial, I’ll walk you through everything you need to know about customizing a SharePoint Online site. No code required for most of it. We’re talking about practical, real-world customization that you can do right now, whether you manage a Team site or a Communication site.

I’ll cover six major areas: site information, applying templates, themes, header and navigation, footer, and some newer features like flex sections and the Brand Center. Let’s get into it.

What Does “SharePoint Customization” Actually Mean?

When people say “customize SharePoint,” they usually mean one of two things:

• Visual customization – changing the look and feel, colors, fonts, logo, and layout
• Functional customization – adding web parts, building pages, setting up navigation, personalizing content for different users

In this tutorial, I’m focusing mostly on the first category — things any site owner can do using SharePoint’s built-in settings. No developer tools, no PowerShell, no SPFx. Just the gear icon and a few clicks.

That said, I’ll also touch on some slightly advanced options (like the Brand Center and Flex Sections) that Microsoft has rolled out recently — because they’re genuinely useful and not enough people know about them.

1. Change SharePoint Site Information (Name, Description, Privacy)

This is the most basic but often overlooked customization. The site information panel lets you update your SharePoint site name, add a description, and control privacy — all in one place.

Here’s how to get to it:

1. Open your SharePoint site
2. Click the gear icon (top right corner)
3. Select Site information

Inside the panel, you’ll see these options:

• Site name – This is required. Change it to something that clearly describes the site’s purpose
• Site description – Optional, but worth filling in. It shows up in search results and helps people understand what the site is about
• Privacy settings – Choose between Private (only approved members can access) or Public (anyone in your organization can access)
• View all site settings – This takes you to the classic site settings page, where more advanced options live
• Delete site – Only use this if you’re absolutely sure. There’s no undo button here

A real-world tip: Don’t leave the site description blank. When someone searches for this site in Microsoft 365, that description shows up right below the title. A good description helps people quickly decide if this is the site they’re looking for.

2. Apply a Site Template

SharePoint comes with a library of pre-built site templates from Microsoft. These are not just visual themes — they bring in entire page structures, pre-configured web parts, and content layouts specific to different business scenarios.

Some popular templates include:

• Store Collaboration – For retail or frontline teams
• Crisis Communication – For emergency announcements
• Human Resources – For HR portals with onboarding resources
• Learning Central – For internal training and learning content

Here is a screenshot for your reference; you can see a few templates.

To apply a template:

1. Click the gear icon
2. Select Apply a site template
3. Browse the available templates and click on one to preview it
4. Review the site capabilities shown in the preview panel
5. Click Use template to apply it, like in the screenshot below:

One thing to keep in mind: your existing data is safe. Applying a template changes the look and layout of your home page and may add new pages, but it doesn’t delete your lists, libraries, or content. You can access everything from Site contents after the template is applied.

If you ever want to go back to the default home page, just go to the Site Pages library, find Home.aspx, click the three dots (…) next to it, and select Make homepage. Here is a screenshot for your reference:

This is how to apply a SharePoint template.

Check out How To Create Custom Site Template In SharePoint Online?

3. Change the Theme (Colors and Fonts)

This is where it gets fun. SharePoint lets you change the entire color palette of your site in just a few clicks.

Option A: Use a built-in theme

1. Click the gear icon
2. Go to Change the look
3. Click Theme
4. Pick from the available color themes and click Save, like in the screenshot below:

Microsoft provides a decent range of built-in themes. But if your organization has specific brand colors, you’ll want to go further.

Option B: Create a custom theme using the Brand Center (newer feature)

Microsoft recently introduced the Brand Center — a dedicated SharePoint site at the tenant level where IT admins or designated brand managers can define company-wide fonts, colors, and themes.

Here’s the basic flow:

1. Set up the Brand Center (your Microsoft 365 admin does this once)
2. In the Brand Center, go to Add Colors and define your brand hex color codes
3. Then go to Font packages and themes → Add theme
4. Build your theme using the brand colors you defined

Once published, site owners across your organization can apply this custom theme to their own sites — without any PowerShell or code.

Option C: Site-level custom theme (site owners can do this)

Even without the Brand Center, site owners can now create a simple custom theme directly on their site:

1. Click Gear icon → Site branding
2. Go to the Themes tab and click + New theme
3. Define your colors (you can use hex codes directly)
4. Give it a name and click Save

This is perfect when you manage a site that needs to match a specific department’s branding, without waiting on IT.

4. Customize SharePoint Site Header

The header is the first thing people see when they land on your SharePoint site. Customizing it well makes a huge difference in how professional and organized your site looks.

To access header settings:

1. Gear icon → Change the look → Header

You’ll see four sections:

Layout options:

• Minimal – Clean and compact; just the logo and site name
• Compact – Slightly more space; works well for communication sites
• Standard – The default layout
• Extended – Gives you a large banner-style header with more room for branding

Background:
Change the background color of the header bar to match your theme or brand color.

Display options:

• Toggle the Site title on or off
• Upload a custom Site logo (use a PNG with a transparent background for best results)
• Set a Site logo thumbnail for compact header display

Once you’re happy with the changes, click Save.

Practical example: For a company intranet homepage, I usually go with the Extended layout, upload the company logo in white, and set the background to the company’s primary brand color. It immediately makes the site feel branded and intentional.

5. Customize SharePoint Site Navigation

Navigation is what helps people find things on your site. Poor navigation is the number one reason people give up on SharePoint sites. Let’s fix that.

Go to Gear icon → Change the look → Navigation

Here you can control:

Site navigation visibility:
Toggle the navigation on or off entirely. For sites that are single-page or landing pages, turning off navigation can actually look cleaner.

Orientation:

• Vertical – Navigation appears on the left side (default for Team sites)
• Horizontal – Navigation appears at the top

If you go horizontal, you also get to choose between:

• Mega menu – Shows a large dropdown grid, great for sites with many subsections
• Cascading – Traditional dropdown menu

Here is a screenshot for your reference.

My recommendation:

• For Team sites used by a small team → stick with vertical navigation
• For Communication sites used as company intranets → go with horizontal + mega menu. It handles lots of links much better and looks more polished

Below is a SharePoint team site left navigation, check the screenshot below:

You can further edit the actual navigation links by clicking Edit on the navigation bar itself. From there, you can add links, reorder items, and create sub-links.

Check out Create a Dropdown Navigation in SharePoint [With Sublinks]

6. Customize the Footer (Communication Sites Only)

This one surprises a lot of people — the Footer option is only available on Communication sites, not Team sites. If you’re on a Team site and don’t see it, that’s why.

To access footer settings:

1. Gear icon → Change the look → Footer, follow the screenshot below:

You’ll get these controls:

• Enable – Toggle the footer on or off
• Layout – Choose between Simple (single row) or Extended (multi-row with more links), like in the screenshot below:

• Logo – Add a footer logo (company logo or department icon)
• Display name – The label that appears in the footer, like your company name or site name
• Background – Change the footer background color

After saving, you can also click Edit directly on the footer to add navigation links and labels — similar to how you edit the top navigation.

Good use cases for the footer:

• Links to legal/compliance pages
• Contact information or support links
• Links to related sites in your organization
• Social media links for company-wide communication sites

Check out SharePoint Site Left Navigation or Quick Launch

7. Add and Customize Web Parts on Pages

Beyond the site-level settings, you can also customize individual pages by adding and configuring web parts. Think of web parts as the building blocks of your pages.

To add a web part to a page:

1. Click Edit on the page (top right)
2. Hover over a section and click the + button to add a web part
3. Search for the web part you want

Some of the most commonly used web parts for customization include:

• Hero – A visual banner-style section great for homepages; supports images, titles, and links
• News – Automatically pulls in recent news posts from your site or across your SharePoint environment
• Quick Links – A clean, icon-based link section for directing users to key resources
• Highlighted Content – Dynamically surfaces documents, pages, or sites based on filters you set
• People – Displays profile cards for specific team members
• Events – Shows upcoming calendar events
• Text and Image – For adding formatted content with supporting visuals

New Flex Sections:
Microsoft recently introduced Flex Sections as a major upgrade to how you lay out page content. With Flex Sections, you can freely move, resize, overlap, and group web parts on a 2D grid — giving you much more design freedom than the older column-based layout.

To use a Flex Section:

1. While editing a page, click the + Add a section option
2. Choose Flexible layout
3. Now you can drag and drop web parts anywhere within that section and resize them freely

This is a huge upgrade if you’ve ever felt constrained by SharePoint’s default 1-, 2-, or 3-column layouts.

Check out SharePoint Editorial Card Web Part

8. Customize Site Pages vs. Home Page

Here’s something that trips people up: the Home page of a SharePoint site is just one page in the Site Pages library. You can create multiple pages and set any of them as the new homepage.

To create a new page:

1. Click Gear icon → Add a page
2. Choose a page template or start from blank
3. Customize it with web parts
4. When ready, click Publish

To make a different page the homepage:

1. Go to Site contents → Site Pages
2. Find the page you want
3. Click the three dots (…) next to it
4. Select Make homepage

Why would you do this?
Say you applied a template and don’t love the default home page it created. You can build a completely custom page and swap it in as the homepage without touching anything else the template set up.

9. Personalized Content with Audience Targeting

This is one of the more powerful but underused features in SharePoint. Audience targeting lets you show specific content only to certain groups of users — while everyone else sees something different (or nothing at all).

For example, you could set up a news web part on your intranet homepage to show HR-specific announcements only to the HR team, while the IT team sees IT-related updates in the same space.

Here’s how to enable it:

For a web part:

1. Edit the page
2. Click on the web part you want to target (e.g., News, Highlighted Content, Quick Links)
3. In the web part settings, look for Enable audience targeting and turn it on
4. Now you can target specific Microsoft 365 groups

For a news post or document:

1. Go to the SharePoint library or list
2. Open the settings and enable Audience targeting on the library/list itself
3. Add the target audience column to the items you want to target

This works best when your users are properly organized into Microsoft 365 groups or security groups — which is another reason to keep your Azure AD groups tidy.

10. Quick Branding Tips That Make a Real Difference

Before I wrap up, here are a few quick wins that I always recommend when customizing a SharePoint site:

• Use a transparent PNG logo – It blends cleanly into any background color
• Stick to 2–3 brand colors – More than that starts looking chaotic
• Match your header background to your main brand color – It immediately looks intentional
• Keep navigation items under 7 – More than that and people start ignoring the menu
• Use the Hero web part on the homepage – It adds visual weight and makes the page feel designed, not assembled
• Add a site icon (favicon) – Go to Site information → Site logo and upload a square icon. It shows up in browser tabs and search results

Team Site vs. Communication Site: What Can You Customize?

People often ask whether the customization options differ between the two site types. Here’s a quick breakdown:

The Footer is the big one — it’s exclusive to Communication sites. Everything else is available on both.

Here is a video I recorded and uploaded to the YouTube channel on SharePoint site customization.

Conclusion

Customizing a SharePoint Online site doesn’t have to be complicated. Start with the basics — update your site name, apply a theme that matches your brand, set up the header and navigation, and drop a few well-chosen web parts on your homepage. That alone will make your site look 10x better than a fresh out-of-the-box install.

Once you’re comfortable with those, move on to things like audience targeting, custom themes via the Brand Center, and Flex Sections for more advanced layout control.

The goal is a site that feels like it was built for your team — not just a generic SharePoint template that nobody wants to use.

You may also like:

• SharePoint Calendar Color Coding
• How To Add a Calendar in SharePoint Online
• When to Use OneDrive vs SharePoint for File Storage

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