Repository navigation
Access denied on folder with Form Customizer #9893
Description
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested
- 💥 Internet Explorer
- 💥 Microsoft Edge
- 💥 Google Chrome
- 💥 FireFox
- 💥 Safari
- mobile (iOS/iPadOS)
- mobile (Android)
- not applicable
- other (enter in the "Additional environment details" area below)
Additional environment details
- browser version
- SPFx version
- Node.js version
- etc
Describe the bug / error
When a user only has Edit rights on a particular folder in a list (but Read on the list itself), form customizer page (SPListForm.aspx) generates Access Denied error when attempting to access New form for that folder. It seems it is checking permissions for the list, but not for the folder.
Steps to reproduce
- Create a form customizer SPFx solution
- On a list, enable folders and create a folder
- Grant a user Edit rights on the folder, but Read rights on the list
- When user attempts to add an item to the folder, SharePoint produces Access Denied error on SPListForm.aspx page, although the RootFolder query string parameter points to the folder that the user has Edit rights to
Expected behavior
When RootFolder query string parameter exists and points to an allowed folder, permissions check should succeed and form should operate normally.
Activity
Ashlesha-MSFT commentedon Apr 24, 2025
Hello Vladimir Gubler (@vladigubler),
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
Ashlesha-MSFT commentedon Apr 24, 2025
Vladimir Gubler (@vladigubler),
In step 3. Grant a user Edit rights on the folder, but Read rights on the list,
I am not able to give such permission.
Without that case, I ran basic form customizer, I won't get any access error.
vladigubler commentedon Apr 24, 2025
That's the whole point. Read access on the root and write access on the particular folder. Maybe your user doesn't have admin access?
Ashlesha-MSFT commentedon May 15, 2025
It seems to be a limitation or possibly a platform issue in how permissions are evaluated during form rendering via SPListForm.aspx.
We are checking with Microsoft to confirm whether this is a known issue or a bug in SharePoint Online.
Ashlesha-MSFT commentedon Aug 4, 2025
Vladimir Gubler (@vladigubler),
Just wanted to share an observation that might help clarify the issue.
When Edit permission is removed at the list level, it effectively removes Edit access on all items and folders within that list — even if you've explicitly granted Edit rights at the folder level. This seems to be why the Access Denied error occurs when accessing the custom form (SPListForm.aspx), as SharePoint appears to prioritize list-level permissions during form rendering.
Given this behavior, it’s likely Microsoft may consider it by design. That said, I’ll go ahead and raise a feature request to support folder-specific permission evaluation during form customization, as it’s a valid use case for many scenarios.
vladigubler commentedon Aug 5, 2025
I understand that, but you would agree that it's not an acceptable behaviour. I should be able to enter information into a folder I am allowed to, if it has unique permissions, even if for the level up I don't have permissions. That's the whole idea of unique permissions and breaking inheritance after all. Otherwise it just makes no sense.
VesaJuvonen commentedon Nov 3, 2026
This issue is more than 12 months old and has not had recent activity. We are cleaning up the backlog so we can manage incoming reports more efficiently. If the issue is still relevant, please submit a new issue with updated details and current reproduction steps. We apologize for any inconvenience caused by this updated process, and thank you for being part of the SharePoint developer ecosystem.
github-actions commentedon Nov 3, 2026
Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.
If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.
We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.