Power App + SharePoint: Project IDs Changing, Blank Mandatory Fields, Record Overwrites

(0) Share

Report

Posted on by RM-04061217-0

Environment

Power App connected to a SharePoint List backend.
SharePoint List contains approximately 4,500 records and 34 columns.
Users create and update allocation records through the Power App.
Project ID is a mandatory field in the Power App.

Issue Summary
We are investigating several data integrity issues affecting a Power App that uses a SharePoint List as its backend.
At this point, we are not certain whether the root cause lies in Power Apps, SharePoint, Patch logic, concurrent updates. The reason is that we are observing multiple different types of data inconsistencies rather than a single isolated issue.
Some records appear to have changed after being successfully stored, while other records contain values that should not be possible based on the frontend validation rules.
Important Observation
We have historical CSV exports from SharePoint showing that certain records contained valid Project IDs at an earlier point in time.
However, when reviewing the same records later, some of those values had changed, become blank, or appeared under a different allocation than expected.

Observed Symptoms

Project IDs changing after allocation

We have identified records where users originally allocated an individual to one project, but later the Project ID changed to a completely different Project ID.
In some cases, the replacement Project ID belongs to a different project than the one originally selected.

Blank Project IDs despite being mandatory

Project ID is a mandatory field in the Power App.
Despite this, we have found multiple records in SharePoint where the Project ID is blank.
Because users cannot intentionally submit an allocation without selecting a Project ID, we are trying to determine:

Whether the value never reached SharePoint.
Whether the value was removed during a Patch operation.
Whether the value existed initially and was later cleared by another update by Sharepoint

Allocation month changing unexpectedly

We have observed cases where allocation information appears to have shifted to a different month.
For example, a Project ID that was originally associated with one Month-Year combination later appears associated with a different Month-Year combination.
This creates concerns about records being overwritten or updated incorrectly.

Possible record overwrites

Some records appear to have been replaced while retaining the same SharePoint Item ID.

Version history inconsistencies

When reviewing SharePoint version history, we found cases where timestamps shown in version history do not appear to align with the timestamps shown in Modified By / Modified fields.
In several instances, updates appear to have occurred at times that do not match the activity we would expect from users.
This has made it difficult to trace exactly when certain changes occurred as in whether in Power Apps or SharePoint or how?

Multiple users affected

The issue is not isolated to a single user, project, or allocation!! We have observed these behaviors across multiple allocation records.
What We Have Already Checked

SharePoint list contains approximately 4,500 rows and 34 columns.
We reviewed SharePoint List View Threshold documentation.
Historical CSV exports from SharePoint.
SharePoint version history on affected records.

Based on the list size, we do not believe List View Threshold limitations alone should result in Project IDs changing, records being overwritten, or mandatory fields becoming blank.
Questions

Has anyone encountered similar behavior where data stored through Power Apps later changed unexpectedly in SharePoint?
Are there known Power Apps scenarios where mandatory field values can end up blank in SharePoint even when frontend validation exists?
Has anyone seen allocation records shift between Month-Year values due to Patch logic or update conflicts?
Why might SharePoint version history and Modified timestamps appear inconsistent for the same record?
What is the best way to determine whether the issue originates from:
- Power Apps,
- SharePoint backend behavior,
- Concurrent update conflicts,
- Or another process modifying records after they are saved?

Any guidance, debugging approaches, or similar experiences would be greatly appreciated.Environment

Categories:

Error handling

Building Power Apps

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

RaghavMishra 97 on at

Like (0)

Report
Copy link

Link copied!

Hi! You've described a classic set of symptoms that point to two well-documented root causes in Power Apps + SharePoint: delegation limits and Patch function behavior with stale records.

Root Cause 1 — Delegation limit (most likely culprit)

Your SharePoint list has ~4,500 records. By default, Power Apps only retrieves the first 500 records from SharePoint when a query is nondelegable. This means users selecting a Project ID may be seeing a truncated list — accidentally picking a value that maps to the wrong project. You can raise the limit to 2,000 in Settings > Advanced Settings > Data row limit, but for 4,500 rows the correct fix is to use only delegable functions (e.g., Filter on indexed columns with supported operators).

Reference: https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/delegation-overview

Root Cause 2 — Patch function overwriting with stale data

The Patch() function updates only the fields you explicitly specify — but if the Patch call is built from a form or local collection loaded before another user saved changes, the values patched may be stale. This can cause one user's Patch to overwrite another's changes (same SharePoint Item ID, different values), and mandatory fields can become blank if a variable was never initialized before Patch runs.

Reference: https://learn.microsoft.com/en-us/power-platform/power-fx/reference/function-patch

Root Cause 3 — Unindexed columns

Columns not indexed in SharePoint can return inconsistent results on large lists. Ensure your Project ID and Month-Year columns are indexed in the SharePoint list settings.

Reference: https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/connections/connection-sharepoint-online

Recommended investigation steps:

1. Check all Filter() / LookUp() calls for delegation warnings (yellow triangles in Power Apps Studio)

2. Raise the data row limit to 2,000 and index key columns in SharePoint

3. Audit every Patch() call — ensure it always includes the ID field and that variables are initialized on screen load

4. Add Notify(FirstError().Message) error handling around Patch calls to surface hidden failures

5. Check if any Power Automate flows are also writing to the same SharePoint list in parallel

Found this helpful? Please mark ✅ "Does this answer your question?" so others searching for the same issue can find it quickly. A 👍 on "Was this reply helpful?" or a ♥ Like is also much appreciated!

Raghav Mishra — LinkedIn | PowerAI Labs

Was this reply helpful? Yes No
WarrenBelz 155,491 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @RM-04061217-0,

I have been using SharePoint with Power Apps across multiple customers for over 8 years on some List and Libraries exceeding 100k records/files and have never encountered data integrity issues as you describe (records being changed without intervention from something writing to them).

The threshold limit where field  indexing becomes an issue is 5,000, but is always a good practive to index any columns used in Lookup.Filter/Sort operations from the start (although your problem I do not believe lies there). Delegation is generally only an issue on queries - writing a single record should not be an issue (or are you bulk updating).

I will focus on these two statements you posted

We have historical CSV exports from SharePoint showing that certain records contained valid Project IDs at an earlier point in time.However, when reviewing the same records later, some of those values had changed, become blank, or appeared under a different allocation than expected.



   The fact that your version history shows the correct data at a point in time strongly suggests that something subsequent to that record writing is changing the record.

So let's start with "concurrent" writes - how many users to you have and what is the possibility of two of them having the same record open at once ? There are ways to (almost) manage this if necessary.

What mechanisms do you use to write to the List (SubmitForm, Patch etc) and when and where are these triggered ? For instance do you use anything OnSuccess of a Form (if you submit it), this can be a subsequent write. Also do you have any Flows writing to the List ?  Please post all relevant code and where it is used and we should be able to progress this.

Please ✅ Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like ♥
Visit my blog Practical Power Apps    LinkedIn



Was this reply helpful? Yes No