Permission drift
People change roles, sharing links get created in a hurry, and inheritance gets broken on individual folders. Two years of small exceptions is how a tenant ends up with access nobody can explain.
After go-live
Projects end at launch; the tenant keeps running for years. SharePoint support and maintenance is the work that happens afterwards — permissions drifting as people change roles, libraries filling with versions nobody reads, search quietly missing documents, a flow that failed three weeks ago. We scope each of those as a fixed-fee piece of work with senior US-based engineers, not as a monthly monitoring contract.
Representative dashboard — sample data
The usual damage
None of these announce themselves. They surface as “I can’t find the contract” or “why can the intern see that folder”, usually a year or two after launch.
People change roles, sharing links get created in a hurry, and inheritance gets broken on individual folders. Two years of small exceptions is how a tenant ends up with access nobody can explain.
Tenant storage is a pooled allowance, and versions, recycle bins and abandoned sites all draw from it. The bill for ignoring it arrives as a purchase order or, eventually, as read-only sites.
A renamed column, a changed managed property or a library excluded from search results in documents that exist but cannot be found. Staff stop trusting search long before anyone reports it.
An approval routes to a person who left, a connection expires, a list column is renamed. The flow turns itself off, and the first sign is a process that everyone assumed was still running.
A departing employee owned three sites, two flows and a shared library. Removing the licence does not reassign any of that, and orphaned ownership is the most common cause of a site nobody can administer.
A new department needs a site, a library needs two more metadata columns, a retention rule needs adjusting. Each is an hour of work that waits six months because no one is responsible for it.
Most pages selling ongoing care are vague about the edges, which is how a client ends up calling about a broken laptop. This is a fixed-fee project practice, not a managed service provider: there is no helpdesk queue, no 24/7 monitoring, no SLA and no device management here, and the only way to reach us is the form on this page. The table below is the boundary, written so you can check it before you get in touch.
| The request | Handled here? | Notes |
|---|---|---|
| Audit and rebuild permissions across sites and libraries | Yes | Who can see what today, an agreed group-based model, then a staged rollout site by site |
| Reclaim tenant storage and set version-history limits | Yes | Version storage reported before anything is trimmed, recycle bins and dormant sites reviewed |
| Fix search that is missing or mis-ranking documents | Yes | Search schema and managed properties checked, site and library indexing settings corrected |
| Repair or rebuild a failed Power Automate flow | Yes | Connection ownership, expired credentials and renamed columns are the usual three causes |
| Reassign sites, flows and files left by a departing employee | Yes | Ownership moved before the account is removed, so nothing becomes unadministrable |
| Add a new site, hub, library or metadata column | Yes | Scoped as a small change against the existing structure, not a fresh build |
| 24/7 monitoring, alerting or a guaranteed response time | No | We reply within one business day; overnight cover with an SLA belongs to a managed service provider |
| End-user helpdesk — passwords, mailboxes, “how do I” tickets | No | That is your internal IT or MSP; we train your site owners instead of taking their tickets |
| Laptops, patching and endpoint management | No | Device work is a separate project — see Intune deployment for small business |
| Building a new intranet or document-management structure | No | That is a build, not maintenance — see SharePoint consulting |
| Moving content in from a file server or another platform | No | Migrations are scoped and priced separately — see file server to SharePoint migration |
Care work is quoted the same way a build is: a written scope and one fixed fee, approved before anything starts. Book a single cleanup, or re-authorize a review whenever you want one. There is no minimum term, no monthly commitment, and nothing to cancel.
How it works
A senior engineer looks at sites, permissions, storage, indexing and flow-run history without changing anything. You get the findings in writing, in priority order, whether or not you go further.
The findings turn into a list of specific fixes, each with what changes and what the user-visible effect is. You approve the list and the fixed fee before a single setting is touched.
Changes are staged — one site, confirmed working, then the rest. What was changed and why is documented in your own tenant so your team, or anyone after us, can follow it.
Nothing in the list above is a defect in SharePoint or a sign the original project was done badly. They are the predictable consequence of people using a system: staff join and leave, someone shares a folder to hit a deadline, a library grows past the shape it was designed for, and a department invents a process the intranet was never told about. A site that was correct at handover is a site that was correct on one particular day.
What makes the drift expensive is that it compounds silently. Individual permission grants are the clearest example. SharePoint supports up to 50,000 unique permissions per list or library, but Microsoft's published SharePoint service limits (opens in new tab) put the recommended working limit at 5,000 — and note that once a list, library or folder passes 100,000 items you can no longer break or re-inherit permissions on it at all. Nobody crosses those lines deliberately. They arrive one “just give Dave access to this one folder” at a time.
Support requests on a mature tenant cluster into a short list. The table below is the triage we run before quoting, and it is written so you can use it to diagnose your own environment before talking to anyone.
| Symptom | Usual cause | What the fix involves |
|---|---|---|
| “The wrong people can see this” | Broken inheritance, direct grants to individuals, and sharing links created ad hoc over several years | Map current access, agree a group-based model, remove per-item exceptions, stage the change site by site |
| “We are out of storage” | Version history with no limit, full recycle bins, dormant sites and duplicated migration content | Report version storage first, set organization or site version limits, empty recycle bins, retire dead sites |
| “Search cannot find a document that exists” | Managed property or schema changes, a library set to be excluded from search, or content never reindexed | Check the search schema and site settings, correct the mapping, then request a reindex and verify results |
| “The approval stopped arriving” | A flow owner who left, an expired connection, a renamed list column, or an unhandled error loop | Read the run history, repair or rebuild the flow, move ownership to a service account or shared owner |
| “Nobody can administer this site” | The only site owner left the company and the account was deleted before ownership was reassigned | Restore administration, assign at least two owners per site, and fix the offboarding checklist that allowed it |
Two of those deserve a caution. Version cleanup is genuinely destructive: Microsoft's guidance on version history limits for document libraries (opens in new tab) is explicit that versions removed by a limit or a trim job bypass the recycle bin and cannot be recovered, though content under a retention policy or eDiscovery hold is exempt. So the version storage report comes first and the trim job second, always. Search is the opposite problem — the risk is impatience. Microsoft's own note on manually requesting a reindex (opens in new tab) warns that reindexing a site puts heavy load on the search system and should not be used as a first response, which is exactly how most in-house attempts to fix search begin.
The obvious commercial model for this work is a monthly fee for an agreed number of hours. We do not offer one, because it would be the wrong shape for the same reason our builds are fixed-fee: you would be paying a steady amount for work whose volume is lumpy, and we would be incentivised to make each request small. Instead a review produces a list of specific fixes, each one described by what changes, and the whole list carries a single fixed fee you approve in writing. How our fixed-fee process works is the same for a permission audit as it is for a build.
If you are still in a project rather than after one, the other SharePoint pages are the right starting point. An initial build — information architecture, libraries, permissions model, governance — is covered under SharePoint intranet and document management consulting, and the week-by-week version of that sprint is set out in what a SharePoint intranet in 30 days really looks like. If you are budgeting rather than buying, what drives SharePoint intranet cost breaks down the build side and SharePoint migration cost for a small business covers moving existing content in. All three of those end at go-live. This page begins there. And where the same faults keep coming back because no rule stops them — access granted person by person, sites created by anyone, links that never expire — the answer is policy rather than repair, which is what our SharePoint governance consulting services design and configure once rather than fixing each time.
The typical fit is an organization of roughly 20 to 200 people on Microsoft 365 with a SharePoint environment that already works, no dedicated SharePoint administrator, and an IT provider who keeps laptops and mailboxes running but does not go near information architecture or the search schema. Often the person calling inherited the tenant from whoever set it up and has no documentation of how it was meant to be organized.
It fits badly in two cases, and both are worth saying out loud. If what you need is someone on call overnight with a contractual response time, that is a managed service provider and not us — Microsoft 365 consultant vs MSP sets out where that line falls and what each kind of provider is actually selling. And if the tenant is so tangled that a rebuild is cheaper than a repair, we will say so during the review rather than sell a cleanup that will not hold — in which case the conversation moves to a build, or to Teams governance if the sprawl arrived through Teams rather than through SharePoint itself. The same boundary applies on the Power Platform side: this service keeps working things working, so a Power Apps or Power Automate build that never worked in the first place is a one-off intervention instead, scoped as our Power Platform project rescue services. Work is delivered remotely across all US states from our Orange County, CA base, by senior US-based engineers.
Related services
The build itself: information architecture, document libraries with metadata, a permissions model, migration, and governance designed to survive handover.
The week-by-week build sprint, the exit criteria for each week, and an honest list of what does not fit inside a first month.
A read-only review of the wider tenant — identity, conditional access, external sharing, DLP — when the concern is broader than SharePoint.
FAQ
Neither. Every piece of care work is scoped in writing and quoted as a fixed fee before it starts, exactly like a build. Some clients book one cleanup and never come back. Others re-authorize a review each quarter. Nothing recurs automatically, and there is no contract you have to cancel.
We are not a 24/7 operation and we will not pretend otherwise. There is no pager, no monitoring service and no response-time guarantee here. Contact is by web form and we reply within one business day. If you need overnight cover with an SLA, a managed service provider is the honest answer.
Yes, and most of this work is on tenants somebody else set up. The first step is a read-only review of sites, permissions, storage and failed flows, which is what makes a fixed quote possible. You get the findings in writing whether or not you hire us for the remediation.
By changing group membership rather than individual grants, and by staging it. We map who has access today, agree the intended model with you, apply it to one site first, and keep the old access in place until that site is confirmed working. Nothing is removed on the strength of an assumption.
It can, which is why limits are modelled before they are applied. Microsoft's version storage report shows what a proposed limit would remove, and versions deleted by a trim job bypass the recycle bin permanently. Content under a retention policy or eDiscovery hold is exempt and is not touched.
Hypercare covers the settling-in period after handover and is included in the build fee. After it ends, your team runs the site using the documentation you own. This page exists for later, when something has drifted and you want a senior engineer to fix it as a defined piece of work.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.