> ## Content Index > Fetch the complete content index at: https://todayfixtech.com/llms.txt > Use this file to discover other available public pages before exploring further. # Microsoft Lists blocked — find the cause and restore access - URL: https://todayfixtech.com/microsoft-lists-blocked/ - Published: 2026-10-30T07:21:41.000Z - Updated: 2026-10-30T07:21:41.000Z - Author: Md Sojib Mia - Tags: Troubleshooting “Microsoft Lists blocked” means the Lists web app or the Lists experience in SharePoint won’t load or returns an access/policy error. The usual fixes are: confirm the exact symptom and scope, [check Microsoft service health](https://todayfixtech.com/fix-microsoft-365-login-issues/) and tenant settings (license, SharePoint settings), validate Conditional Access / app permissions / Intune policies, and rule out local or network blockers (browser cache, extensions, proxy/firewall). Follow the ordered checks below and collect HAR and Azure AD sign-in logs if you need to escalate to Microsoft support. ## What does “blocked” look like right now and who is affected? Start by reproducing and recording the symptom before you change anything. ```text User cannot open lists.microsoft.com or the Lists app within SharePoint; page shows an error, blank page, or a message saying access is blocked by policy. ``` Symptom When it appears - Note whether the error appears immediately on navigation, after sign-in, or when performing an action (open, create, edit item). Checklist to ask the user (one quick list you can read over the phone): - Exact error text or a screenshot. Copy the whole message if present. - URL shown in the browser address bar (`lists.microsoft.com`, `tenant.sharepoint.com`, or an app link). - Device type and OS (Windows/macOS/iOS/Android). - Browser and version, or the mobile app name/version. - Network they are on (office, home, mobile tether). - Whether other users can access Lists and whether the same user can access from another device or network. Reproduce yourself in this order: 1\. Use the user's browser and profile if possible. 2\. Try the same URL on your admin machine. 3\. Test a different browser or an Incognito/Private window. Each test narrows scope: single user vs group vs tenant-wide, browser-specific vs network-specific. ## Before you start Applicability: this [guide applies to Microsoft](https://todayfixtech.com/microsoft-365-security-features/) Lists and the Lists experience hosted on SharePoint Online. It assumes the tenant is using Microsoft 365 and modern SharePoint. - Product: Microsoft Lists and SharePoint Online. - Privileges needed: to check tenant settings and service health you need a Microsoft 365 Global Admin or a role with Service Health and license visibility. To inspect Conditional Access you need Azure AD Conditional Access administrator or Global Admin. To view device/compliance policies you need access to Microsoft Endpoint Manager. - Restart/backup: no restart or backups are required for the checks below. Safe checks to run first: - Confirm service health and the user’s license assignment (admin-level checks). - Reproduce the error in a private/incognito browser or on an alternate network (user-level checks). ## Could Microsoft be down or is this a tenant-level restriction? Before chasing local causes, confirm the service is healthy and the tenant allows Lists. Steps to check service and tenant settings 1. Open Microsoft 365 admin center Service health and check for an incident affecting Lists or SharePoint. ```text Microsoft 365 admin center > Health > Service health ``` Settings path 1. Check the Message center for recent tenant-level changes that might disable features. ```text Microsoft 365 admin center > Health > Message center ``` Settings path 1. Verify the affected user has a license that includes Lists/SharePoint Online. ```powershell Connect-MsolService Get-MsolUser -UserPrincipalName user@domain.com | Select DisplayName, Licenses ``` PowerShell (run as Administrator) Expected results and meaning - Service health shows no incident: proceed to tenant controls. If there's an incident affecting Lists/SharePoint, follow Microsoft guidance and inform users. - Message center shows a change: follow the action described. - User has appropriate license: licensing likely not the blocker. If not licensed, assign a suitable license and test. Check if Lists is disabled via SharePoint settings 1. In the SharePoint admin center, ensure access to classic and modern experiences is permitted and that the Lists app is not blocked. ```text SharePoint admin center > Settings ``` Settings path If you find a tenant setting explicitly disabling Lists or modern SharePoint experiences, re-enable it and test with the user. If settings are already correct, move to Conditional Access and app permissions. ## Is conditional access, security policy, or app permission blocking Lists? Conditional Access, Intune app protection, and Azure AD app consent can block access even when service and licensing are correct. Start with the least disruptive checks and use a temporary exclusion to prove a policy is responsible. Where to act and privileges - Privileges: Azure AD Conditional Access administrator or Global Admin for testing. - Work in the Azure portal; do not delete policies as a first step. Inspect Conditional Access policies 1. Open Azure AD > Security > Conditional Access and list policies targeting the affected user or group. ```text Azure Active Directory > Security > Conditional Access ``` Settings path 1. Look for policies that block access, require compliant devices, restrict client apps (browser excluded), or limit access by named locations. 2. Check policy conditions: Users and groups, Cloud apps (SharePoint Online or Microsoft 365 apps), Conditions (Locations, Client apps), and Access controls (Grant -> require device to be marked compliant, require app protection). Only exclude one test user and document the change; don’t broadly disable the policy. Simple test: temporarily exclude one affected user from a suspect policy 1. Edit the policy and add the single test user to the Exclude list under Users and groups. Expected result - If the test user can access Lists after exclusion, the policy is responsible. If not, policy is unlikely the direct cause. App permission and consent checks 1. In Azure AD > Enterprise applications, open the SharePoint Online and Microsoft Lists-related apps and check whether the app is disabled or requires admin consent. ```text Azure Active Directory > Enterprise applications > [SharePoint Online] ``` Settings path Device management and Intune 1. In Microsoft Endpoint Manager, verify app protection policies and device compliance policies applied to the user. Policies that block browser access or require app protection on mobile can prevent Lists from working. ```text Endpoint Manager admin center > Apps > App protection policies ``` Settings path If a device compliance or app protection policy is the blocker, either adjust the policy scope or remediate the device to meet compliance (for example, enroll the device or enable required settings). ## Could local browser, cache, or network rules be the culprit? Local and network issues are common and easy to test. Run the safest, most reversible checks first. Where to act and privileges - Privileges: user-level on the endpoint; admin on firewall/proxy for logs. Local browser and device tests (do these first) 1. Ask the user to open the URL in a private/incognito window. 2. Try a different browser on the same device. 3. Clear cached credentials for the site or sign out of Office browser sessions and sign in again. 4. Test the same account on a different device or on a mobile device tethered to a phone network. 5. If using the Lists mobile app, try the browser and vice versa. Example steps to clear credentials in Edge/Chrome 1. Open browser > Settings > Clear browsing data > Cached images and files and Cookies and other site data. Network and proxy checks - Check firewall/proxy logs for blocked requests to these hosts: `lists.microsoft.com`, *`.sharepoint.com`, `login.microsoftonline.com`, and* `.msauth.net`. If you have URL filtering, verify these domains aren't blocked. - If possible, ask the user to connect via a mobile hotspot to rule out corporate network rules. What to look for in logs - Requests receiving HTTP 403, 407, or connection reset when contacting `lists.microsoft.com` or `tenant.sharepoint.com` indicate network blocking or authentication interception. When a browser extension might be the problem 1. Ask the user to disable privacy/adblock extensions or test in an extension-free profile. If all local checks clear but the problem persists, collect a HAR file and Azure AD sign-in logs for escalation. ## How to verify the problem is resolved and collect evidence for escalation Verification checklist 1. The user opens `https://lists.microsoft.com` (or the SharePoint Lists URL) and can view lists. ```text User navigates to lists.microsoft.com, page loads, user can open a list and create or edit an item without an access or policy error. ``` Expected output 1. Test the same device, browser, and network that originally failed. 2. Confirm other affected users can access if the issue was group- or tenant-wide. What to collect before escalating to Microsoft support - Screenshot of the exact error message and the browser address bar. - HAR file captured during a failed request (browser DevTools > Network > Save as HAR). - Azure AD sign-in logs for the user at the time of failure: timestamp, client IP, application, conditional access result, and failure reason. ```text Azure Active Directory > Sign-ins ``` Settings path - Conditional Access insights and reporting: the policy evaluation for the failed sign-in. - Tenant and request trace IDs: include them if they appear in the error page or sign-in logs. If you open a Microsoft support ticket, include: - Exact time (with timezone) of attempts. - HAR file, screenshots, sign-in log entries, conditional access report, and steps already tested. ## How to prevent this again and common FAQs you'll run into Durable fixes and runbooks - Document Conditional Access policies that apply to Microsoft 365 apps and add test accounts or break-glass exclusions for troubleshooting. - Whitelist Microsoft endpoints in corporate proxies and firewalls: `lists.microsoft.com`, `*.sharepoint.com`, `login.microsoftonline.com`, and associated authentication domains. - Add clear device enrollment and remediation steps to Intune device compliance profiles so users know how to regain compliant status. - Maintain a support runbook for "Lists blocked" that lists quick tests: private window, different browser, hotspot, temporary CA exclusion, and collecting HAR/logs. Common FAQs Q: Is Microsoft Lists the same as SharePoint? A: Lists is a Microsoft 365 app built on SharePoint; lists opened from `lists.microsoft.com` are backed by SharePoint Online. Permissions and some admin controls live in SharePoint and Azure AD. Q: Do I need a separate license for Lists? A: No separate license: Lists uses SharePoint Online licensing which is included in most Microsoft 365 plans. Verify the user's license includes SharePoint Online if access is missing. Q: When should I open a Microsoft support ticket? A: Open a ticket when you have tenant and user evidence (HAR, Azure AD sign-in logs, conditional access evaluation) and you suspect a backend service issue or cannot resolve a tenant-level configuration problem. Preventive note - Periodically review Message center notices for changes that could affect Lists and test Conditional Access policy changes in a pilot group before wide rollout. ## Conclusion If quick checks (service health, license, private browser, hotspot) don’t show the problem, focus next on Conditional Access, Intune/device compliance, and proxy/firewall rules. Collect HAR files, screenshots, and Azure AD sign-in/conditional access reports before escalating to Microsoft support. ## Frequently Asked Questions ### Why does Lists work for some users but not others? Different users can be targeted by Conditional Access, Intune, or group-scoped SharePoint permissions. Also license assignment, device compliance, or network segmentation can cause uneven behavior. Compare user group membership, applied policies, and license state to find differences. ### Can a firewall block only Lists but allow SharePoint? Yes. URL filters or application rules can block specific hostnames or paths. \`lists.microsoft.com\` might be blocked while \`tenant.sharepoint.com\` is allowed; check proxy logs and URL allowlists to verify. ### Is there a quick way to prove Conditional Access is the problem? Temporarily exclude a single test user from the suspect Conditional Access policy. If the user immediately regains access, the policy is implicated. Use this as a controlled test and re-enable the policy after testing.