What SharePoint Is Actually Good At
The decision that shapes a SharePoint project is made before any configuration, at the point where someone decides what is actually being built. SharePoint is a document store with metadata, versioning, permissions, and search on top of it, plus a lightweight list engine and a way to publish pages. What gets built with it is assembled from those parts.
SharePoint Online is included in the Microsoft 365 business and enterprise plans, so if your organization runs one of those, the platform is already licensed and already running. Availability is not the same as fit, which is why the parts are worth understanding properly rather than either defaulting to them or dismissing them. Version history that nobody has to remember to switch on, co-authoring in Word and Excel instead of emailed attachments, search that reads inside documents, and access that follows a site rather than a folder on a file server are defaults, not features somebody has to build.
That distinction carries more weight than it sounds like it should. A design that stays close to those defaults stays close to what Microsoft maintains on your behalf. A design that works around them becomes something you maintain, and that is the point where the friction starts, when the same parts are asked to behave like an application platform.
Where SharePoint Fits Without a Fight
There is a shape of problem SharePoint handles well. Documents are the point, the structure is flat or close to it, and the rules around them are simple.
Where a problem has that shape, SharePoint does not need much help. Metadata columns instead of nested folders, a couple of saved views, a library template, and a short piece of training about where things go. The cases below all share that shape.
- Policy and procedure libraries, where version history and an approval step are the requirement.
- Project, client, or job sites created from a template so every engagement has the same shelves.
- Controlled external sharing, where a customer or subcontractor needs a few files and not a VPN account.
- Intranet pages and internal news, especially when the alternative is another all-staff email.
- Flat lists where each row stands on its own: an equipment register, a request log, a list of sites.
- Retention, holds, and the ability to show what a document looked like on a given date.
Where Does SharePoint Start Fighting You?
The friction has a source worth naming. It comes from the list engine being asked to act like a relational database.
A useful tell is the word “and.” Store the signed contracts is a SharePoint request. Store the signed contracts, and derive renewal dates, and hold the covered line items, and block a submission when coverage overlaps an existing agreement is a database request wearing SharePoint’s clothes. The places where that second request meets the platform are specific.
- Data with real relationships. A lookup column can enforce restrict or cascade delete against one parent list, but that is the limit of it. Nothing keeps a wider set of related lists consistent, and nothing joins them for you.
- Volume. Large lists run into view thresholds that call for indexed columns and filtered views. It is workable, and it is worth planning while the list is small rather than after it fills.
- Validation that spans records. Column and list validation can compare fields inside a single item, but checking a value against another list, or against other items in the same list, is beyond what those formulas do.
- Anything transactional. If two records must both change or neither should, a list gives you no way to guarantee it.
- Reporting across lists, or reporting on how a value changed over time. Version history exists per item and is not built for analysis.
- Item level permissions applied row by row, which add a maintenance surface that has to be reasoned about every time the list or the team changes.
Is SharePoint a Database?
No, and settling that early keeps it a design question rather than a structural one later. Lists are a good fit for flat data owned by one team and read by that team. When data has parents and children, when several processes write to it, or when the same record has to be right for two departments at the same time, it belongs somewhere built for that. Dataverse, SQL Server, or the ERP or CRM that already claims ownership of the customer and the asset.
The consequence for a SharePoint design is narrower than it first looks. Keep the list a place for documents and the metadata that describes them, and let it point at the record rather than restate it. A column that mirrors a field owned by another system is a copy, and copies drift.
If what pushes you toward copying is a reporting requirement, that is an integration question rather than a SharePoint one, and it is better answered on its own terms than solved with a second set of columns.
Permissions and Migration Are Part of the Fit Question
A fit that works on paper can still come apart in two places: who is allowed to see what, and what happens to the content that already exists.
Permissions are worth settling before content arrives. The goal is not maximum control. It is the smallest number of places where access is decided, because every exception is something a future administrator has to reconstruct.
Migration is the same problem seen from the other end. Lift and shift moves the mess along with the files. That is sometimes the right call, when a file server is being decommissioned on a fixed date and cleanup can follow. It is a poor default when the reason for the project was that nobody can find anything, because the new system inherits exactly that. Permissions nobody can explain are where the two questions meet, and they are a decision to make before the move rather than during it.
- Break inheritance as little as the requirement allows, and when you must, break it at the site or library level rather than per item.
- Grant access to groups, never to named individuals. Somebody leaving should not require an archaeology exercise.
- If two audiences need genuinely different access to the same content, that is a case for two sites rather than one site with exceptions.
- Guest access needs an expiry and a review date set when it is granted, not discovered afterward.
- Sensitivity labels do something site permissions cannot. A label that applies encryption travels with the file after it leaves the site.
- Metadata that lives in filenames. Contract_2019_FINAL_v3_signed.pdf is a data model, and it needs to become columns.
- Path length and nesting. Deep folder trees plus long names hit limits that surface as files which will not sync.
- Links inside documents. Office files can point at old network paths, and those references are worth scanning for before the move rather than finding them one workbook at a time afterward.
- Version history, and whether you carry it across or leave it in an archive that stays readable.
So Do You Need More Than SharePoint?
The question is not whether SharePoint is any good. It is whether the thing being built is a document problem with rules attached or a data problem with documents attached. Four conditions separate the two, and they are not sequential. Whichever one you can answer first is the one to start from.
If the answers point in different directions, that disagreement is the finding, and it is worth resolving on paper before anything is configured.
- If the requirement is documents plus a light approval or notification, SharePoint with Power Automate can carry it, and anything added on top is another moving part to design and maintain.
- If the data has relationships, rules, and more than one process writing to it, put the record in a database and let SharePoint hold the attachments.
- If the work crosses departments and systems, the real question is integration and handoffs, not where files are stored.
- If nobody can draw the data model on one page, the product decision is not the thing holding the project up. That page is the work.
Related service: Related service: Our Microsoft 365 business solutions page is the place to start if the question is how much of this belongs in SharePoint and how much belongs elsewhere in your tenant.