Microsoft Lists not updating and how to fix it now

When Microsoft Lists doesn’t show recent edits the cause is usually a local cache/browser problem, a view/permission filter, or an automation/custom form that delays or overwrites changes. Start with quick local checks (hard refresh, incognito, another browser) then verify view filters, permissions, and any Power Automate or Power Apps integrations before doing list-level maintenance like reindexing.

Is the problem happening only to me or everyone

Symptom: List items or view not reflecting recent changes (edits, new items, deletes) for you or users.

When it appears: immediately after edits are made, after bulk imports, or intermittently when users report stale content.

Before you act, confirm scope with these quick checks.

1. Hard refresh your browser.

Ctrl+F5

Expected result: the page reloads and shows recent changes. If it does, the issue is local.

2. Open the list in an incognito/private window.

Open a new Private/Incognito window in your browser and navigate to the list

Expected result: if the list updates here, the problem is browser caching or an extension.

3. Try a different browser on the same machine.

Edge or Chrome or Firefox

Expected result: if another browser shows recent changes, the original browser is the culprit.

4. Have a colleague open the same view or open it with another account that has access.

Sign in with another account that has permissions and open the same list view

Expected result: if others see the updates but you don’t, suspect local cache, browser extensions, or account-specific permissions.

5. Check Microsoft 365 Service health for SharePoint/Lists incidents.

What the results mean:

• If only you see stale data: start with browser cache and extensions.
• If one account is affected across machines: check permissions, saved view, or AD/Exchange replication concerns.
• If everyone is affected: escalate to list-level checks and tenant/service checks.

Could it be caching or a browser issue

Start here — these are the fastest, least invasive fixes and often restore the view immediately.

Steps to try locally:

1. Hard refresh the list view.

Ctrl+F5

Expected result: page reloads and shows recent changes. If it doesn't, continue.

2. Clear the browser cache for the site or open a private/incognito window.

Browser settings > Privacy > Clear browsing data (cached images and files)

Expected result: cached list responses are removed and the list should reflect current items. If it still shows old data, continue.

3. Disable browser extensions, especially ad blockers or privacy tools, then reload the page.

Expected result: extensions no longer interfere with List REST/Graph calls. If disabling resolves it, re-enable extensions one at a time to find the culprit.

4. Try a different browser or machine to confirm the problem is not local.

Why cache causes stale views: Lists uses client-side rendering and cached responses. Large lists or views with complex formatting are more likely to show stale data until the browser fetches fresh list data.

Are permissions, views or filters hiding updates

Before changing anything, verify the items exist and you aren’t seeing a filtered view.

Before you start:

• Applies to: Microsoft Lists in Microsoft 365 (SharePoint-backed lists) and the Lists web app.
• Privileges: a site owner or list owner helps for permissions checks; many checks can be done by a regular user.
• Restart/backup: none required for these checks.
• Safe checks: switch to All Items, open item version history, and verify another user’s view.

Steps to verify filters and permissions:

1. Switch to the default All Items view or create a new view that shows all items and columns.

List settings > Create view > Standard View

Expected result: if items reappear, a saved view or filter was the issue.

2. Remove column filters and check for conditional or column formatting that hides rows.

Expected result: items should display normally; if formatting was hiding rows, editing or removing it restores visibility.

3. Check list permissions as a site/list owner.

List settings > Permissions for this list

Expected result: confirm that users have Read/Edit as expected. If permission inheritance was broken or changed, restore correct permissions.

4. Check item-level permissions and version history on an affected item.

Item menu > Version history

Expected result: version history shows recent edits; absence of expected versions suggests edits were rejected or overwritten later.

What it means if these checks fail: a view or permission is hiding items rather than the data disappearing. Fix the view or permissions rather than reindexing.

Is a flow, connector or Power Apps blocking or overwriting changes

Automations and custom forms often delay, reject, or overwrite updates. Inspect these next since they can silently alter data.

Where to act: Power Automate portal, Power Apps, list Integrate menu. Privilege: Flow/Power Apps owner or list/site owner rights.

Steps to inspect and safely test flows:

1. Check recent flow runs that target the list in Power Automate.

Power Automate > My flows > [flow] > Run history

Expected result: successful runs should line up with the time of changes. Failures or retry loops explain why updates didn't persist; if flows overwrite values, you'll see update actions after the user edit.

2. Temporarily turn off suspicious flows or add a conditional bypass for testing.

Disabling flows can stop critical business processes. Disable only if you can restore them or test during a maintenance window.

Expected result: after disabling or fixing the flow/form, user edits persist and version history shows the correct edit sequence.

3. Check connectors for throttling or authentication errors (expired connections cause failed runs that may not apply changes).
4. Inspect Power Apps custom forms attached to the list: open the form in edit mode and check OnSave logic for patches or resets that could overwrite fields.

What it means if these checks fail: if disabling flows makes edits persist, update the logic to avoid immediate overwrites or implement concurrency checks.

Tenant or service issues and list-level maintenance to try next

If local fixes, views, and automations aren’t the cause, use tenant/service checks and list maintenance like reindexing or rebuilding indexes. These steps require site or tenant admin rights.

1. Check Microsoft 365 Service health for SharePoint or Lists incidents.

Expected result: if a tenant-wide issue is active, wait for Microsoft to resolve it.

2. Reindex the list to refresh search/indexed views. Where to act: List settings. Privilege: site/list owner.

List settings > Advanced settings > Reindex List

Expected result: SharePoint will queue the list for reindex; after the crawl completes the view/search-driven results should update. If indexing doesn’t resolve it within a reasonable time, continue.

3. Repair problematic column indexes: remove and recreate complex indexes one at a time.

Removing and recreating indexes on very large lists can impact performance and indexed queries. Perform during low usage.

Steps to rebuild an index:

1. In List settings go to Indexed columns.
2. Remove the problematic index.
3. Recreate a single-column index, then add compound indexes only if necessary.

List settings > Indexed columns > Create a new index

Expected result: filtered queries and views that rely on indexes will return updated results. If reindex and index rebuild fail, collect evidence and open a Microsoft support ticket.

4. If you use search-driven web parts or highlighted content, trigger a site-level reindex or ask a tenant admin to force a re-crawl via the Admin Center.

What it means if these steps don’t fix it: a tenant-level replication/propagation issue or an obscure bug likely requires Microsoft support. Collect timestamps, affected item IDs, user IDs, and version history before opening a ticket.

How to verify the problem is fixed and how to prevent it returning

Verification steps:

1. Have an unaffected user create, edit, and delete a test item and observe the results in your browser and an incognito window.

Expected result: edits appear immediately and persist in version history.

2. Review Version history for affected items to confirm the expected sequence of changes.

Item menu > Version history

Expected result: version entries match the times and users who made changes.

3. Monitor related flows for a short period to ensure no automated process reverts changes. If you disabled a flow, re-enable it and watch the next runs carefully.

Prevention tips:

• Document flows and forms that touch each list and include a short description of their behavior and owner.
• Use sensible indexing: index the columns used in filters and views, but avoid excessive compound indexes on very large lists.
• Avoid multiple flows updating the same fields at the same time; centralize updates or add conditional checks.
• Add a brief test step to any new automation that writes to lists: create a clearly labeled test item first.
• Schedule periodic audits: review flow run histories and list health once a quarter or after major updates.

What to do if the problem returns: collect the timeline (who, when, what changed), export version history for affected items, and open a support ticket with Microsoft including those artifacts.

Conclusion

Start with a hard refresh and an incognito window, then confirm whether a view, permission, or an automation is hiding or changing data. If those checks don’t help, reindex the list and review indexes and flow histories; if the issue persists, gather timestamps and version history and escalate to tenant support.

Frequently Asked Questions

Why do edits sometimes appear and then disappear from a list?

That often means an automation or custom form is overwriting the edit after it’s saved. Check Power Automate run history and the Power Apps form OnSave logic to find and fix the behavior.

How long does reindexing a list take to show changes?

Reindexing queues the list for a crawl and the time depends on tenant load and Microsoft’s indexing schedule. If it’s still stale after a few hours, collect evidence and consider opening a support ticket.