SPFx: how do you restrict row-level list access when users need Read on the site?

Md Atiqur Rahman 0 Reputation points
2026-09-14T07:54:59.7233333+00:00

Environment: SPFx 1.23.2, React, PnPjs v4, SharePoint Online. Lists: Employee, Team, TeamMember, Project.

The situation

Users sit in the site's Visitors group with Read, so the web part can query lists under their own identity. That works, but it means anyone can call /_api/web/lists/getByTitle('Project')/items directly in a browser and read every row, regardless of what the app renders. Role filtering in the web part is UI shaping only.

Salary data is already in a separate list with broken inheritance, so that part is covered.

The problem

The next increment assigns developers to specific projects — they should see only what they're assigned to. Item-level permissions on a list that will grow past 5,000 items looks like a bad idea, but I'd rather hear that from someone who has tried it.

Options I can see

  1. Accept it. Internal tool, colleagues can see each other's work anyway.
  2. Item-level permissions on Project and WorkItem, applied per item on create.
  3. Azure Function middle tier with app-only auth, users holding no direct list access.

Option 3 looks correct but adds a component, a deployment, and cost. Option 2 worries me at volume.

What I'm asking

  • Has item-level permissioning held up on a list in the thousands, or does the unique-permission overhead bite before that?
  • If you went the middle-tier route, was it an Azure Function or something else?
  • Is there a fourth option I'm missing?

Not looking for a compliance-grade boundary — just want the app's access model to mean something rather than being cosmetic.

Microsoft 365 and Office | SharePoint | Development
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Helen Luu 2,865 Reputation points Independent Advisor
    2026-09-14T10:52:47.8233333+00:00

    Hello @Md Atiqur Rahman

    When a SharePoint list or library contains more than 5,000 items, SharePoint's List View Threshold may impact how data is retrieved and processed. As a result, users may encounter errors such as "The number of items in this list exceeds the list view threshold" when attempting to access, query, or process large volumes of data. This limitation can affect standard SharePoint views, item-level permissions, and custom solutions that use Azure Functions, SharePoint REST API, Microsoft Graph API, or CSOM when queries are not sufficiently filtered or optimized.

    Although SharePoint can support lists and libraries containing well over 100,000 items, the ability to successfully execute queries against those items depends on how the data is structured and retrieved. Queries that need to scan a large number of items at once may be throttled, experience performance degradation, or fail if they exceed the List View Threshold or are not optimized through indexing and filtering.

    I would recommend restructuring the data by distributing content across multiple libraries, lists, or separate SharePoint sites. Depending on your business requirements, separating large datasets into dedicated sites or subsites can help reduce the number of items processed in a single query and improve overall performance. Additionally, implementing indexed columns and applying filtered queries can help reduce the likelihood of threshold-related errors.

    I hope this information helps clarify the behavior you are experiencing. Please let me know if you have any questions.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.