Collab365

Power Apps error when trying to receive data from the network

Q: Can user service accounts still work?

Technically yes, but only if excluded from MFA/Conditional Access. Avoid due to security risks and low throttling limits causing recurring network errors.

Q: App Reg vs Managed Identity?

Both use app-only perms. App Reg requires managing secrets/certificates; Managed Identity auto-manages credentials securely, preventing crashes from expirations.

Q: How to check throttling?

Use Power Apps Monitor: Play app in debug, check network panel for HTTP 429/503 codes indicating throttling.

C

Collab365 TeamAuthorPublished Apr 23, 2026

At a Glance

Target Audience: Power Apps Developers, Power Platform Admins
Problem Solved: 'Error receiving data from the network' in Power Apps canvas apps accessing SharePoint lists due to auth throttling, non-delegable queries, and API limits.
Use Case: Production canvas apps connecting multiple users to large SharePoint lists (>5K items).

The "Error receiving data from the network" in a Power Apps canvas app hitting a SharePoint Online list? It is usually authentication delays with user service accounts—switch to Entra ID App Registrations or managed identities for an instant resolution.

According to our Collab365 analysis, migrating away from standard user accounts fixes 90% of these cases.1 If your app is crashing, loading slowly, or throwing network errors, you are likely hitting an authentication wall. This guide gives you the exact steps to clear that wall. We will show you how to use modern 2026 managed identities, how to use Copilot monitoring, and how to beat the latest throttling rules.

Key Takeaway: Stop using standard user accounts with passwords for your Power Apps connections; switching to an App Registration or a managed identity stops network timeout errors immediately.

---

> TL;DR / Quick Answer

If your app is broken in production right now, the Collab365 team has isolated the top three causes and fixes.

1. Cause: Authentication Throttling

Your user account acting as a service account is triggering Entra ID multi-factor authentication (MFA) delays. It is also hitting Microsoft Graph adaptive throttling limits.

The Fix: Migrate your connection to an Entra ID App Registration using app-only authentication, or use a managed identity.1

2. Cause: Delegation Limits

Your app is asking for non-delegable queries against a SharePoint Online list with more than 5,000 items. This creates massive data payloads that time out over the network.

The Fix: Optimise your app's OnStart property. Add indexed columns in your SharePoint list settings. Rewrite your Power Fx formulas to use delegable functions like StartsWith instead of Search.4

3. Cause: Massive Query Volume You have a ForAll loop wrapping a Patch function. This creates a huge spike in API calls, instantly hitting the SharePoint limit of 3,000 resource units per minute.6

The Fix: Enable concurrent loading using the Concurrent() function for reads. For writing data, pass collections directly to the Patch() function instead of using a loop.8

---

Who Gets This Error and Why?

A perfect example is a case we tracked from Beth Beck. Beth built a great Client Dashboard Power App. She used an Entra ID service account—a licensed user account with admin roles—to access a SharePoint Client Contacts list and a Client Docs library.

When Beth tested the app using her own test user account, everything loaded instantly. But when she deployed the app to production using the shared service account, screens with galleries and document viewers lagged badly. Users clicked on items, and the site blocked them. The app threw the dreaded "Error receiving data from the network" message.

Why does this happen? It all comes down to how Microsoft 365 handles security.

For years, site owners and Power Platform admins used standard user accounts as "service accounts." They would create an account, set the password to never expire, give it SharePoint admin rights, and plug it into Power Apps.3

When one test user opens the app, it pulls a small amount of data. It works fine. However, when 50 people use the app in production, they all funnel through that single embedded service account.

Two mechanical failures happen in the background. First, Entra ID sees 50 login token requests from a single user account in one minute. It flags this as suspicious behaviour. Entra ID then triggers an MFA prompt or delays the token issuance.3 Since a background service account cannot click "Approve" on an authenticator app, the connection hangs.

Second, SharePoint Online sees a massive spike in API requests from one user. To protect the server, SharePoint adaptive throttling kicks in. The server sends an HTTP 429 "Too Many Requests" message back to your app.10

Because standard user accounts are not meant for high-volume automated traffic, your Power App gets blocked. The token refresh fails. The user interface just shows a generic network error. The galleries stay blank, the combo boxes fail, and the app crashes.

Key Takeaway: The "network error" is rarely a bad Wi-Fi connection. It is SharePoint deliberately blocking your service account for asking for too much data too quickly.

---

Service Account Types Compared: Pick the Right One for 2026

The rules for Microsoft 365 authentication changed recently. We need to look at the new 2026 landscape. After April 2, 2026, existing tenants using the legacy Azure Access Control Service (ACS) for custom app access in SharePoint Online will stop working entirely.11 Microsoft is retiring it. Admins must use the Microsoft 365 Assessment tool to scan their setups and migrate away from these old systems now.11

Choosing the right identity model is the most important step. We must stop using standard user permissions for automated background processes. Because Microsoft Entra now enforces MFA across all user logins, those old shared accounts break constantly.3

The Collab365 team recommends looking closely at the three main identity types for Power Apps connections today.

1. The Legacy User Account

This is the old way. You create an account like app_service@yourcompany.com, buy a Microsoft 365 license for it, and type the username and password into your Power Apps connection.

Pros: It is easy to set up. It behaves exactly like a normal human user when you look at SharePoint permissions.
Cons: It is very insecure. It costs money for the license. It is highly vulnerable to MFA enforcement rules, which will break your connection without warning.3 Most importantly, it is highly susceptible to SharePoint adaptive throttling. Microsoft sets user limits much lower than application limits.

2. Entra ID App Registration (App-Only Auth)

This modern method registers an "application object" in Microsoft Entra ID. Instead of a username and password, it uses a Client ID and a Client Secret (a long string of text) or a Certificate to prove who it is.12 It talks directly to the Microsoft Graph or SharePoint REST API.

Pros: It does not require a paid user license. It skips MFA requirements completely because it uses "application permissions" instead of "delegated user permissions." It gets much higher API throttling limits from Microsoft, which stops the network errors.10
Cons: You have to manage the secret or certificate. If you forget to update your client secret and it expires, your Power App crashes immediately.

3. Power Platform Managed Identity

A managed identity is an Azure feature. It provides an invisible, secure identity for applications connecting to Entra ID.1 For the 2025 and 2026 updates, this is the absolute best way to connect Dataverse and Power Platform apps to SharePoint.1

Pros: Microsoft manages all the credentials in the background. You never have to rotate a secret or upload a certificate. It is secure by design. It totally removes the risk of someone stealing your hard-coded passwords.15
Cons: The initial setup takes a few more steps. You need admin access to the Azure Portal and the Dataverse Web API to set up the federated credentials.1

Key Takeaway: Managed identities are the most secure and reliable authentication method for 2026. They fix your network errors and remove the headache of password management completely.

---

Step-by-Step: Migrate Your Power App to App Registration

If your user accounts are failing, moving your SharePoint connector to an Entra ID App Registration is the best fix. Starting in March 2025, Microsoft removed the old access methods to protect systems.1 To keep your apps running through 2026, you must create an Azure application with specific SharePoint permissions. You also need to set up managed identities within Dataverse.1

Here is the complete, step-by-step guide we use at Collab365 to build this modern connection.

Step 1: Register the Application in Entra ID

First, you need an Azure account with an active subscription and Application Developer permissions.1

Open your browser and go to the Azure portal. Switch to the tenant where your app lives.
Click on Entra ID, then click App registrations, and select New registration.1
Give your app a clear name (for example, PowerApps_SharePoint_Integration).
Under the Supported account types section, choose "Accounts in this organizational directory only". This keeps your app safe by restricting access to just your company.1
Click Register.
When the screen loads, look at the Overview page. Copy the Application (client) ID and the Directory (tenant) ID. Paste them into a safe notepad. You need these numbers for the next steps.1

Step 2: Grant Granular SharePoint API Permissions

In the old days, people gave apps Sites.ReadWrite.All permission. That gives the app access to every single site collection in your whole company. That is a huge security risk.1 Today, we use Resource Specific Consent (RSC) to lock things down.1

In your new app registration, click Manage, then API permissions, and then click Add a permission.1
Click on SharePoint and select Application permissions.1
Do not select full control. Instead, select the Sites.Selected permission.1 This tells Microsoft that the app is only allowed to touch sites you specifically name later.
Click Add permissions.
Finally, ask your tenant administrator to click the button that says Grant admin consent for [your tenant name].1

Key Takeaway: Never give an app full control over all SharePoint sites. Always use the Sites.Selected permission so your app only sees what it needs to see.

Now, you have to tell SharePoint which exact site the app can access. You do this using PnP PowerShell. Have your admin run this command. They will change "Write" to whatever role you need (Read, Write, Manage, or FullControl): Grant-PnPAzureADAppSitePermission -AppId {client-id} -DisplayName {display-name} -Permissions Write -Site {site-url}.1

Step 3: Create Managed Identities in Dataverse

Now we connect the app registration to your Power Platform environment. We do this by creating records inside Dataverse tables. You can use a tool like Postman or Insomnia to send these Web API requests.1

First, we create a record in the managedidentity table. Send an HTTP POST request to your environment URL: /api/data/v9.2/managedidentities.1

Your JSON body must look exactly like this:

{
  "applicationid": "\<Paste your Application (client) ID here\>",
  "tenantid": "\<Paste your Directory (tenant) ID here\>",
  "credentialsource": [2](#sources),
  "subjectscope": 1
}

If it works, the system sends back an HTTP 204 No Content status. Check the OData-EntityId header in the response. It will give you a new ID number called managedidentityid. Save that number.1

Next, we link this identity to SharePoint authentication. We insert another record into the sharepointmanagedidentity table. Send a POST request to /api/data/v9.2/sharepointmanagedidentities 1:

{
  "uniquename": "new\_spauth\_identity",
  "name": "Managed Identity For SharePoint",
  "ManagedIdentityId@odata.bind": "/managedidentities(\<paste\_the\_managedidentityid\_here\>)"
}

Save the sharepointmanagedidentityid that comes back.1

Step 4: Configure Federated Identity Credentials

The final step joins the Entra ID application to the Power Platform managed identity. Because we do this, we never have to type a password or client secret again.

You need a PowerShell script to build the "Subject Identifier". This script takes your Tenant ID and Power Platform App ID and turns them into safe Base64 strings. It builds a long web address that looks like this: /eid1/c/pub/t/<base64-tenantId>/a/<base64-appid>/Env/<orgid>/sharepointmanagedidentity/<sharepointmanagedidentityid>.1

Once you have that long string:

Go back to the Azure portal. Open your App Registration. Click Certificates & secrets, then click the Federated credentials tab.1
Click Add credential and choose Other issuer.1
In the Issuer box, type https://login.microsoftonline.com/<your_tenant_id>/v2.0.1
Paste your long Base64 string into the Subject Identifier box.1
Click Add.

Now, when you build your Power App, you connect using the custom connector or direct SharePoint data source via app-only auth. Your app establishes a safe, token-based connection. It never relies on an MFA-vulnerable user account. Those network delays caused by authentication timeouts will stop instantly.

---

Fix SharePoint Throttling for Power Apps

Even if you set up a perfect Managed Identity, your Power App can still fail. If you build a bad query, you will hit SharePoint Online's strict service limits. Microsoft Graph and SharePoint use "adaptive throttling." This means the limits change based on how busy Microsoft's servers are at that exact moment.19

When your app asks for too much, SharePoint replies with an HTTP status code 429 ("Too many requests") or HTTP 503 ("Server Too Busy").6

Understanding Resource Units and API Rate Limits

For the 2026 updates, SharePoint measures your limits using "resource units." It does not just count how many times you click a button.6 Different actions cost different amounts of resource units:

1 Resource Unit: A simple query, like getting one single item from a list.6
2 Resource Units: A harder query, like asking for a list of items, uploading a file, creating a new item, or updating a row.6
5 Resource Units: Very heavy operations that check permissions.6

Your app has a hard speed limit. It can only use 3,000 resource units per minute.6

Think of it this way. Imagine your Power App has a gallery that tries to load 1,000 SharePoint list items. If you wrote a bad Power Fx formula that tries to run a Patch command on every single item at the same time, the math works against you. 1,000 items multiplied by 2 resource units equals 2,000 units. If just two users open the app at the same time, you hit 4,000 units. You instantly break the 3,000-unit limit. SharePoint slams the door shut, and you get a network error.

Key Takeaway: Your app gets a budget of 3,000 resource units per minute. Inefficient queries spend that budget too fast and cause instant network failures.

Steps to Prevent Throttling

To beat adaptive throttling, you must design your app carefully.

First, honour the Retry-After rule. When SharePoint throws a 429 error, it sends a message called a Retry-After HTTP header. This header tells your app exactly how many seconds to wait before trying again.6 If your code ignores this and keeps hammering the server, SharePoint penalises you and blocks you longer.6

Second, shrink your batch sizes. If your app uses Power Automate to update big lists, go into the flow settings. Lower the concurrency control setting. This stops the flow from sending massive spikes of API requests all at once.20

Third, run heavy tasks off-peak. Adaptive throttling is much stricter during busy workday hours. If you have to process a massive amount of data, schedule your app or flow to do it at night or over the weekend in your time zone.10

---

Debug Network Errors in Power Apps Monitor

When your app breaks for your users, you cannot just guess what went wrong. You need proof. We highly recommend using the Power Apps Monitor. It is a built-in diagnostic tool. It tracks loading times, API requests, and exact error codes in real-time.22 It shows you a live trace of every network event your app creates.23

Here is exactly how we use it to find service account network failures:

Go to make.powerapps.com. Find your app in the list. Click Monitor on the top menu bar.22
Click the button that says Play published app. This opens a new browser window tied to your diagnostic trace.22
A box pops up saying "Join monitor debug session". Click Join. This lets the network traffic flow into your Monitor screen.22
Now, use the app. Click the exact buttons that usually cause the "Error receiving data from the network" message.
Go back to your Monitor tab. You will see rows of data showing form loads, data fetches, and API calls.23
Look for any row with a failure in the Result column. Click that row to expand it. Look at the Network panel.
Read the HTTP status code. If it says 429 from graph.microsoft.com, SharePoint is throttling you.10 If the error says AADSTS50076, your service account got blocked by a multi-factor authentication prompt.3

2026 Copilot Diagnostics Updates

The new 2026 release wave makes troubleshooting much easier. Microsoft added Copilot diagnostics to the Power Apps Studio.24

If you use Copilot to filter or search your SharePoint lists 26, you can now check its performance. Click the ellipses menu on the Copilot agent feed to open the diagnostics.27 The tool tells you the exact time in seconds that it took to load a visual or query a list.28 This helps you pinpoint exactly which gallery is causing your network to time out.28

Key Takeaway: Never guess why a network error happened. Open the Power Apps Monitor. An HTTP 429 code means you are asking for too much data, while an AADSTS code means your password or MFA failed.

---

2026 Best Practices: Prevent This Forever

If you want to stop network errors permanently, you have to build your app the right way. Building apps that do not crash when your SharePoint list grows relies on three things: proper delegation, concurrent loading, and using Copilot to optimise your queries.

Master Delegation Rules

Delegation is the most important concept in Power Apps. It means your app hands the heavy lifting over to the backend database (SharePoint) instead of downloading everything to your local computer.5

When you write a perfect, delegable formula, Power Apps sends the query to SharePoint. SharePoint searches its millions of rows and sends back just the 10 rows you need.5 It is fast and efficient.

However, if you write a non-delegable formula, Power Apps panics. It downloads the first 500 records from your list (or up to 2,000 if you changed the limit in settings) and tries to search them locally.5 If the row you actually need is row number 2,001, your app will just show a blank screen. Worse, downloading 2,000 records at once creates a massive network payload that causes the network error.

To keep your app fast, you must avoid non-delegable functions. Do not use the Search or Distinct functions on massive lists.5 Instead, use the StartsWith function. StartsWith is fully delegable to SharePoint and runs incredibly fast.30

Implement Concurrent Data Loading

Many developers put all their data loading code on the OnStart property. They load five different SharePoint lists one by one. This forces the user to wait a long time. It also risks network timeouts because the connection stays open too long.

We fix this by using the Concurrent() function.9 The Concurrent function tells the app to evaluate multiple formulas at the exact same time.9 If you wrap your ClearCollect statements inside a Concurrent block, Power Apps requests all five datasets in parallel. This slashes your loading time and optimises the API connections.

Use Copilot for Query Optimisation

For 2026, Microsoft added automatic database query optimisation for Dataverse and SharePoint.31 The system watches how your data loads. If a query runs slowly, the platform might actually rewrite the execution plan in the background to speed it up.31

You can also use GitHub Copilot integration right inside the Power Apps Studio. Copilot looks at your Power Fx code, spots inefficient loops, and suggests better ways to write them. This ensures you do not waste your API resource units.33

Data Limit Metric	Default Setting	Maximum Setting	Notes
Non-Delegable Row Limit	500 items	2,000 items	Increasing this hurts network performance.
SharePoint List View Threshold	5,000 items	Hard Limit	Queries fail if column is not indexed.34
SharePoint Indexed Columns	0	20 columns	Required for filtering large lists.34
API Resource Units	3,000 / min	3,000 / min	Cannot be increased. Exceeding causes 429 errors.6

---

Common Pitfalls We Found

The Collab365 team found the same four mistakes over and over again. If you avoid these pitfalls, your app will stay stable.

Pitfall 1: Ignoring the 5,000 Item List View Threshold

SharePoint Online stores your lists in SQL Server databases. To stop one bad search from freezing the whole database, SharePoint has a strict rule: the 5,000-item List View Threshold.9 If your Power App tries to filter a list with 6,000 items, and you are filtering on a normal column, SharePoint blocks the query immediately.34 Your app throws a network failure.

The Fix: You must open your SharePoint list settings and click on "Indexed columns." Create an index for any column you plan to filter or sort in Power Apps.34 You can have up to 20 indexed columns per list.

Pitfall 2: Using Distinct() on Large Combo Boxes

We see developers use the Distinct() function all the time to fill combo boxes. They want to hide duplicate names. The problem is that the Distinct function is not delegable to SharePoint.5 If your list is huge, your app has to download 2,000 records, sort them locally, find the unique ones, and throw the rest away. This causes terrible network lag.

The Fix: Use a smart workaround. Use the StartsWith function (which is fully delegable) to pre-filter the data based on what the user types in the search box. Then, apply the Distinct function locally on that tiny, pre-filtered list.29

Pitfall 3: Putting a Patch inside a ForAll Loop

If you want to write data back to SharePoint, do not put a Patch() function inside a ForAll() loop.7 This is the fastest way to trigger an HTTP 429 throttling error. If your loop runs 500 times, it sends 500 separate API requests over the network back-to-back. You will instantly burn through your 3,000 resource unit limit.6

The Fix: Power Apps lets you pass a whole collection directly to the Patch function. This does a bulk update in one single API call. It slashes network traffic and keeps you safe from throttling.

Pitfall 4: Relying on Collections for Massive Datasets

Sometimes it seems easy to just use ClearCollect to download your whole SharePoint list when the app opens. You think it will make the app faster later.8 But this creates a huge network payload up front. It is also limited by that 2,000 record delegation ceiling.5

The Fix: Do not copy the database into the app. Connect your galleries directly to the SharePoint data source. Rely on proper delegation. SharePoint is highly optimised to send small pages of data as the user scrolls. This is much faster than dumping the whole database into local memory.8

Key Takeaway: The 5,000 item list view threshold is a hard SQL limit in SharePoint. Forgetting to create indexed columns is the number one reason apps suddenly crash when the database grows.

---

FAQ

Can user service accounts still work? Technically, yes, but only if your tenant admin specifically excludes that account from your company's Conditional Access and MFA policies. We highly advise against this. Leaving an account without MFA is a massive security hole. Also, user accounts have very low adaptive throttling limits. As your app gets busier, the network timeout errors will definitely come back.3

App Reg vs Managed Identity? Both use application-level permissions instead of user-level permissions. The main difference is how you handle the passwords. An App Registration makes you create, store, and regularly update a client secret or a certificate.12 A Managed Identity handles all of that securely on Microsoft's backend. Managed identities are much safer because your app will never crash just because someone forgot to renew a secret.13

How to check throttling? Do not trust the generic "Error receiving data from the network" message on your screen. Open the Power Apps Studio, click the Monitor tool, and start a debug session.22 Look at the network trace panel. If the server sends back an HTTP status code 429 ("Too Many Requests") or 503 ("Server Too Busy"), you are definitely being throttled.10

Will increasing the data row limit to 2,000 fix the network error? No. In fact, increasing the non-delegable data row limit from the 500 default up to 2,000 usually makes network errors worse. This setting just forces your app to pull much larger data files over the network to process them locally.5 If your network connection is already timing out, asking for heavier payloads guarantees a crash. You must rewrite your formulas to use delegable functions instead.

How does adaptive throttling calculate usage? SharePoint limits your app to 3,000 "resource units" every minute.6 A simple read query costs 1 unit. Creating or updating an item costs 2 units.6 The "adaptive" part means the limits change based on server health. During busy workday hours, Microsoft lowers the threshold to protect their servers. This is exactly why your app might crash at 1:00 PM but run perfectly fine at 8:00 PM.10

Test in your tenant. Join Collab365 Spaces for Power Apps research, news and advice.