Power Apps’ “Error when trying to receive data from the network” is a symptom, not a diagnosis. It does not, by itself, prove that SharePoint is down, that your app needs an app registration, or that you have hit a delegation limit.
The useful evidence is the failed operation and its response. Start with Live monitor, reproduce the failure as the affected user, and read the event’s status code and response. Microsoft’s troubleshooting guidance uses the same distinction: 403 points towards access, 404 towards a missing resource, 429 towards throttling, while status 0 or a proxy-generated 403, 407, 502 or 503 can indicate that the call was blocked before it reached the Power Platform service.
This guide gives you a safe order of investigation.
Fast triage
| What you observe | Investigate first |
|---|---|
| It fails for one user but works for the maker | App sharing, data-source permission and that user’s connection |
| It fails for everyone after a list, table, column or flow changed | Stale app metadata, renamed/deleted resources or a schema/type mismatch |
Monitor shows 401 or 403 |
Expired connection, wrong identity or insufficient permission |
Monitor shows 404 |
Wrong site/list/table/record, moved resource or environment mismatch |
Monitor shows 409 |
Edit conflict or another service-specific conflict |
Monitor shows 429 |
Connector or destination-service throttling; reduce repeated calls and honour retry guidance |
Monitor shows 5xx |
Service, gateway, proxy or transient upstream failure; capture the response and correlation details |
Monitor shows status 0, (failed) or (canceled) |
Browser, proxy, firewall, TLS inspection, DNS or client network path |
| The app returns incomplete records without a failed network event | Check delegation separately; a nondelegable query can return only a local subset |
Do not redesign authentication until you have this evidence.
1. Reproduce the same operation in Live monitor
Live monitor records events from Power Apps Studio and published canvas apps, including network calls, data operations, errors and performance information.
Use the smallest reproducible test:
- Record the app version, environment, data source and affected user.
- Open Live monitor for the app.
- If only another user can reproduce the problem, use a monitored published-app session rather than testing solely as the maker.
- Perform one failing action: open the screen, refresh the gallery, submit the form or press the save button.
- Select the failed event and capture the operation, data source, status, response and request or correlation identifier. Redact tokens and personal data before sharing the trace.
- Compare it with the same action from a working account or device.
Microsoft’s canvas-app debugging guide explicitly recommends comparing data operations across users or environments. A 403, 404 and 429 require different fixes; the banner alone cannot tell you which one you have.
2. Capture the real formula error
Do not hide the generic banner and continue as though the write succeeded. Handle the operation where it can fail.
For a Patch, a basic pattern is:
Set(varSaving, true);
IfError(
Set(
varSavedRequest,
Patch(
Requests,
Defaults(Requests),
{
Title: txtTitle.Text,
RequestedBy: User().Email
}
)
),
Notify(
"The request was not saved: " & FirstError.Message,
NotificationType.Error
)
);
Set(varSaving, false)
IfError, FirstError and AllErrors can expose the error message, source and—where Power Apps has network details—the HTTP status and response. Errors() can report errors from earlier data-source changes such as Patch, Collect, Remove and SubmitForm.
Use App.OnError for consistent reporting or telemetry, not as a substitute for handling the failed write. Microsoft notes that App.OnError runs after the error has already flowed through the formula; it cannot make the operation succeed.
If you log diagnostics, keep them operationally useful and privacy-safe: app version, screen, control, operation, data source, status and a correlation ID. Do not write access tokens or full connector responses into a list.
3. If it fails for one person, test all three access layers
Sharing a canvas app does not automatically grant access to everything behind it.
Check:
- The app: Is the affected person or their group allowed to run the published version?
- The connection: Does the connector require the person to create or authorize their own connection? Is an existing connection broken or signed in as the wrong account?
- The data: Can that person open the SharePoint list, Dataverse table, SQL source or other resource outside the app and perform the required action?
Microsoft’s resource-sharing guidance for canvas apps explains that some connections are shared implicitly while others require users to create their own connections and receive separate security privileges. For SharePoint Online, start with the normal SharePoint connector and user permissions.
Do not replace a normal user connection with an app registration or managed identity merely because the banner contains the word “network.” That is an architectural and security decision, not a generic repair switch.
After fixing or recreating a connection, open the app in Studio, refresh the affected data source, save and publish a new version. Test as a non-maker.
4. If the status is 0 or the request never reaches the service
HTTP status 0 is different from a service returning an ordinary 4xx or 5xx response. Microsoft’s HTTP 0 troubleshooting guidance covers browser cancellations and intermediary devices such as proxies, firewalls and TLS-inspection products.
Run controlled comparisons:
- affected device versus a known-good device;
- corporate network versus an approved alternative network;
- the same browser with extensions disabled, where policy permits;
- affected account versus a known-good account on the same device;
- web player versus the Power Apps mobile client, if the app supports both.
Give the network team the timestamp, request URL host, status, client/network combination and correlation details. Do not ask them to broadly allow every Microsoft domain without first matching the current Power Platform endpoint guidance to your environment.
5. If a data operation fails, check schema and values
When an app starts failing after a SharePoint or Dataverse change, inspect the exact failing field.
Common causes include:
- a renamed, deleted or recreated column;
- text sent to a number, date, choice, lookup or person field;
- a required field that is blank;
- a record that was deleted or changed by another user;
- a form still holding old metadata after the data source changed;
- a file or attachment exceeding a connector or service boundary;
- a flow, custom connector or gateway that exists in one environment but not another.
Build a minimal test that reads or writes only the required fields. If that succeeds, restore optional fields one at a time. This is faster and safer than deleting every connection or rebuilding the app.
6. Delegation is important—but it is a different problem
Delegation determines whether Power Fx can send a query to the data source. A nondelegable formula is processed locally and Power Apps limits the records considered—500 by default, configurable up to 2,000. That can produce incomplete or misleading results.
It does not mean every generic network banner is a delegation error.
Treat a blue delegation warning as a correctness defect in its own right. Check the connector’s supported operations, simplify the filter, and test with more records than the local limit. In Live monitor, repeated getRows calls can also point to an inefficient formula.
7. Deal with throttling from the evidence, not a made-up universal quota
Connector and destination-service limits differ. If the response is 429, inspect the connector’s current documentation and the response’s retry information. Reduce unnecessary calls—for example, repeated connector calls inside a gallery row—and avoid automatic refresh loops.
Use Concurrent() only for independent operations. Microsoft’s Concurrent function documentation is explicit that formulas inside the block must not depend on one another. Concurrency can reduce elapsed time, but it can also increase simultaneous calls; it is not a universal throttling fix.
A production-safe verification checklist
Before closing the incident, verify:
- the affected non-maker can run the published version;
- their app, connection and data-source permissions are all correct;
- the failing operation returns success in Live monitor;
- an invalid input produces a useful error and no partial success;
- loss of network produces a clear failure state;
- rapid double-clicks cannot create duplicate records;
- large data sets return correct results beyond the delegation limit;
- the app works on every supported device and network path.
Keep the original trace and the successful retest. “It works for the owner” is not release evidence.
Frequently asked questions
Does this error mean SharePoint is down?
No. It can represent permissions, a stale or broken connection, a missing resource, a schema mismatch, throttling, an intermediary network failure or a service problem. Read the failed operation in Live monitor.
Should I fix it with an app registration or managed identity?
Not by default. Ordinary canvas apps commonly use connector connections and the current user’s authorized access. Choose an application identity only for a deliberately designed and supported architecture with an explicit permission and ownership model.
Is a delegation warning the same as a network error?
No. Delegation can make a query incomplete or slow because only a local record subset is processed. Diagnose it separately unless the monitored failure shows that the query itself is causing the network problem.
Why does the app work for me but not another user?
The maker may have app, connection and data-source rights that the other user does not. Test all three layers and reproduce the published app under the affected identity.
What evidence should I capture for support?
Capture the UTC time, environment, app and version, affected user category, operation, data source, HTTP status, sanitized response, correlation identifiers and whether the same action works for another user or network.
If you want help turning a redacted monitor trace into a reliable fix, join the Power Apps Builders Space. Bring the failed operation, status code and the smallest formula that reproduces it.