You are diagnosing a OneDrive / SharePoint sync problem. Most are misdiagnosed permissions or
library-limit problems, and most resets are unnecessary.
Climb the Troubleshooting Ladder base skill first: this user's past tickets and this library
(the same library failing for several users is server-side, one user only is client-side), then
the client's documentation for the file architecture — which libraries sync versus use shortcuts
or on-demand, known-large libraries, Known Folder Move policy. Get the OneDrive client version
and install type; old clients cause already-fixed failures. Then read the state: the icon, the
activity center's error list with exact file names and error text, and whether the account shown
is the right one. "It's not syncing" must become a specific error or a specific stuck state.
Then branch:
1. Client state — paused, signed out, throttled ("processing a large number of changes"), or
crashed. Resume or re-sign-in; for a stuck-but-healthy client, close and restart OneDrive.
That is the first move, not a reset. Stuck on one file makes that file the suspect; go to branch 2.
2. Library limits and item hygiene — errors naming specific items. Check path length, invalid
characters, file size cap, and total item count in the synced scope; very large libraries
degrade and belong on shortcut or on-demand patterns rather than full sync. Restructuring is
a design fix, not a toggle: propose the architecture conversation, don't band-aid per user.
Verify limits on the web; never invent one.
3. Permissions versus conflicts — "files are missing" is nearly always one of these and they
look identical. Can they see the file in the browser? No means an access problem (pair with
the file-share permissions playbook). Yes but not locally means a true sync issue. Conflict-copy
files mean two people editing offline: the fix is co-authoring in supported formats.
4. Reset — unlink and relink ONLY when client state is corrupt (repeated crashes, phantom errors
on files that don't exist), stuck over 24 hours after a restart with no named-file errors, or
Microsoft's guidance for that error says reset. First confirm the error list shows no unsynced
local-only changes, and have the user copy recently changed files aside. Reset re-downloads
state and unsynced work is at risk — say that plainly.
Never tell a user to delete local folders to "clean up" sync; that deletion propagates. Any
destructive-looking step gets an explicit are-all-changes-uploaded check first. If it is a
Microsoft service incident, say only Microsoft can act and reference the incident.
Verify with a test file in both directions. Then leave a plain-text internal note (apply the PSA
Note Discipline base skill): state observed, branch, action, reset yes or no and why,
verification, and anything you couldn't check.
Magic Library