Forum Discussion
Access Denied Error in SharePoint List Board View During Drag-and-Drop for some users
Hi dharam2
Pl refer some workaround which might help
1.Switch from “Contribute” to “Edit” Permission Temporarily
- In some cases, Contribute permission may not be sufficient for Board View drag-and-drop, especially if:
- The field being updated has workflow triggers
- Or if it's connected to Power Automate/Flows
Try giving an affected user Edit permission temporarily and retest.
2.Disable and Recreate the Board View
- A corrupted or partially cached view can cause this:
- Delete and re-create the Board view using the same field.
- Do not clone or reuse the old view via Save As.
3.Force Refresh Permissions via PowerShell (if inherited)
Sometimes inheritance looks intact but is not. You can reassert it via PowerShell:
# Force re-inherit permissions for all items
Get-PnPListItem -List "Your List Name" | ForEach-Object {
Set-PnPListItemPermission -List "Your List Name" -Identity $_.Id -InheritPermissions
}
Backup first and test on a subset!
4.Use Classic Grid View for Updates (Temporarily)
If business critical, advise users to use Grid View (Quick Edit) until Microsoft resolves the Board View issue.
5.Raise Microsoft Support Ticket
This is increasingly being reported on:
- Microsoft 365 forums
- Admin center messages (some tenants are seeing advisories)
If you're a Microsoft 365 admin, check Health Center or raise a ticket. This may be a rolling update bug.
Hi Surya_Narayana , Thank you for giving some workarounds.
Switching permission from 'Contribute' to 'Edit' worked but we don't want to give user higher access. So, why it does not work with 'Contribute' access? This happens for this specific SharePoint list (connected to Power Automate Flows) and there is no issue with any other lists, it even works with 'Contribute' access.
Hi dharam2 , here is my answer
Why It Works with 'Edit' but Not 'Contribute'
1.'Contribute' vs. 'Edit' – Subtle Differences in Metadata Rights
While both Contribute and Edit allow users to read, add, and modify items, Edit also allows:
- Managing list metadata (columns, views, content types)
- Modifying items in ways that involve more than just the item's fields—such as updating system properties or triggering flows.
In drag-and-drop, the action may update internal metadata or fire Power Automate flows—which could require permissions beyond standard Contribute access, depending on how the flows are configured.
2.Power Automate Flow Permissions Could Be the Culprit
Since this list is connected to flows, here's what can happen:
- When an item is moved (dragged), a status column changes → triggers a flow.
- If that flow tries to:
- Modify the item again,
- Access restricted columns,
- Update system fields (like Modified By), or
- Run in the context of the calling user (not a service account),
...then the action may require Edit-level access.
This means the Access Denied error doesn’t come from the drag-drop action itself, but from the follow-up action, likely when the flow tries to run or update something under the Contribute-level user.
3.Why Other Lists Work Fine
- Other lists might not have flows, or
- Their flows might not perform additional actions requiring higher access, or
- They might be running under elevated service accounts (e.g., 'Run as Owner')
So the same user with Contribute can update those lists without triggering permission errors.
Troubleshooting Steps
1.Check Flow Settings
- Open each Power Automate flow connected to this list.
- Go to: Settings > Run only users
- Confirm whether the flow runs:
- As the user who triggered it (default), or
- As the owner or service account (recommended for stability and permission elevation)
Try switching the flow to "Run as Owner" if the owner has Edit or Full Control. This may resolve the Access Denied issue without changing the user's list permissions.
2.Audit the Flow’s Logic
- Check whether the flow:
- Modifies the list item again
- Calls SharePoint REST APIs
- Reads from restricted lists or lookup fields
If any of these actions require more than Contribute, they’ll cause issues unless elevated.
3.Create Custom Permission Level
If absolutely needed, you can create a custom permission level based on Contribute, and add just enough extra rights (e.g., "Manage Personal Views" or "Approve Items") without giving full Edit.