SharePoint At KUMC Is A Mess And Everyone Pretends It Is Not
I have been working in health IT for a long time, and I still get emails asking me to troubleshoot SharePoint issues. People assume it is just a file storage system. It is not. It is a permissions nightmare wrapped around a document management tool that behaves differently depending on which browser you use, whether you are on campus or remote, and what your Active Directory group membership looks like that week. Here is the part nobody tells you during orientation. SharePoint site collections at KUMC are not managed by a single IT team. They are distributed across departments, each with their own governance standards or lack thereof. You will inherit broken inheritance chains from teams that no longer exist. You will find documents locked by users who retired three years ago. The audit logs exist but are nearly impossible to query without PowerShell, and even then the data goes back only so far depending on which compliance tier your site was provisioned under. I spent about six hours once trying to track down why a shared laboratory protocol kept reverting to an older version. The version history showed nothing suspicious. The checkout status was clean. It turned out someone had set up an automated flow through Power Automate that copied files between libraries every night at 2 AM, and the copy operation was overwriting checked-in versions with outdated ones. The flow was owned by a former postdoc who had left the department. Nobody knew about it except the system itself.
What You Actually Need To Know Before Using It
SharePoint is not a replacement for a proper document control system if you are handling anything regulatory. I say this because I have watched people try to use it for ISO documentation anyway. It can work, but you need to understand the limitations. Audit trails in SharePoint are logged, yes, but they are scattered across multiple tables in the backend database. Pulling a clean compliance report requires either third-party tooling or significant Powershell scripting. The permission model is where most people hit the wall. SharePoint supports three levels: full control, edit, and read. But those map onto AD groups, and those AD groups are often shared across dozens of projects. When you remove someone from a project, they may still retain access through an unrelated group they joined two years ago. I learned this the hard way when a researcher on a terminated grant could still view a clinical documentation library because their primary appointment group had not been updated.
Practical Workarounds That Actually Help
If you are managing a SharePoint site and want some control, start with breaking permission inheritance at the folder level rather than trying to manage individual document permissions. It is less granular but far more maintainable. From personal experience, going after individual item permissions on a site with more than two hundred files is a losing battle. The UI becomes unstable, and the backend query performance degrades noticeably. For the version issue I mentioned earlier, the workaround was straightforward once I found the flow. I documented it for the team: first check the Power Automate connections in the site admin center, second filter by last modified date, and third check for any flows associated with deleted user accounts. Took me maybe twenty minutes once I knew what to look for instead of the six hours of aimless troubleshooting. Another thing that helps is setting up a monthly permission review. Not a quarterly one. Monthly. AD group drift at a medical center happens constantly because of hiring cycles, contract rotations, and the eternal problem of people joining and leaving multiple departments simultaneously. A thirty-minute monthly check where you pull the site visitors list and cross-reference it with current HR records catches most of the issues before they become incidents.
Get the Full Details
Where SharePoint Simply Fails
There are scenarios where you should not bother with SharePoint at all. If you need real-time collaborative editing on large Word documents with tracked changes across more than fifty concurrent users, you will hit throttling issues and conflict resolution becomes unreliable. If your data classification requires encryption at rest with key management separate from Microsoft's infrastructure, you are going to run into compliance gaps unless you invest in Microsoft Purview configuration that most IT departments do not have time to set up properly. Mobile access is another weak point. The SharePoint mobile app for iOS and Android is functional for viewing and basic editing, but anything involving metadata management, bulk operations, or custom forms falls apart. I have had colleagues try to use it in clinical settings where staff are on their feet and need quick access, and the friction causes them to fall back to email attachments anyway, which defeats the entire purpose of having a centralized system. For heavy document control work in a regulated environment, I would recommend pairing SharePoint with a dedicated solution like Documentum or even a well-structured shared drive with backup monitoring. SharePoint works fine as a secondary collaboration space. It is not built to be the single source of truth for anything that matters legally or clinically.
