SharePoint Is a Great Tool Right Up Until It Isn't. Here Is Where the Line Is.

Business systems rarely get designed. They accumulate. Someone needs to track something, so they make a list. It works, so a second list appears. A flow gets added to keep the two in sync. A year later there are eleven lists, thirty-something flows, and a handful of workarounds that made perfect sense to whoever wrote them.

Nobody made a bad decision anywhere in that sequence. Every individual step was the reasonable one. That is precisely why this is worth writing about: the trouble does not come from a mistake you can point at, it comes from a tool being carried past the range it was built for, one sensible step at a time.

I am not here to tell you SharePoint is bad. I have used it, built on it, and recommended it. It is a good tool with a very specific shape, and most of the pain around it comes from asking it to be a shape it isn't. So let me lay out both sides honestly, including where the honest answer is that you should keep using it.

What SharePoint and Power Automate Are Genuinely Good At

The reason low-code took over the SMB world is not marketing. It is that you can see a result the same afternoon. That feeling is real and it is valuable.

Here is where SharePoint earns its keep:

Internal news and announcement sites. Communication sites with a news web part are excellent. Fast to build, easy to maintain, no developer required. If you need an intranet homepage, this is the right tool and a custom build would be a waste of money.

Document management. Libraries, versioning, co-authoring, retention, and permissions that ride on the accounts you already have in Entra ID. This is SharePoint's home turf. It is a genuinely good document management system.

Trivial data structures. A vendor contact list. An equipment register. A policy acknowledgment tracker. Anything that is fundamentally one flat table with some metadata on it. Lists are fine for this. Better than fine.

Power Automate is the same story. It is very good at the small automations that eat an hour a week:

• A PTO request form routes to the manager, waits for approval, writes the result to a list, and drops a message in the team's Teams channel.
• A new file lands in a library, gets stamped with metadata, and the owner is notified.
• A contract list is scanned nightly, and anything expiring in the next 30 days emails the account owner.
• A new-hire record triggers a Planner checklist, a welcome email, and a folder created in the right place.
• An invoice email attachment gets saved to the AP library and posted for review.

None of that needs a developer. All of it saves real time. If this is where you are, stop reading and go build it.

Where It Starts to Fall Apart

The trouble starts when the business asks for more, and the thing you built is the only place that data lives.

Building a real ERP or a real CRM on SharePoint lists is not impossible, but it is a fight. And the fight is with the platform, not with the problem.

The data model is not relational. Lookup columns look like foreign keys and behave like a polite suggestion. You get twelve lookup-type columns in a single view before queries start failing, and that count includes Person and Managed Metadata columns, so a normal-looking form hits it faster than you expect. Calculated columns cannot reference lookups at all. Referential integrity is opt-in: if you do not explicitly turn on restrict or cascade delete, deleting a parent record leaves orphaned references behind, silently.

The 5,000-item list view threshold. This is the famous one, and it has not moved since SharePoint 2010. A list can hold 30 million items, but any single query that has to scan more than 5,000 gets blocked rather than served. It cannot be raised in SharePoint Online. The workarounds are real: indexed columns, filtered views, archiving, querying through search instead. They all work, and every one of them is a design constraint you now have to carry forever. Your reporting view is not "show me all open orders." It is "show me all open orders, filtered first by an indexed column, in slices."

The threshold and relationships collide. You cannot turn on cascade or restrict delete for a lookup on a list that is already over the threshold. Cascade delete is capped at 1,000 items per operation. So the exact moment your data grows to the point where integrity matters is the moment the platform stops letting you enforce it.

No transactions. There is no way to write a header row and its five line items as one atomic operation. If the flow dies halfway, you have half a record. You can write compensation logic, and now you are writing distributed systems code inside a workflow designer.

No trustworthy server-side validation. Column validation is a formula on the list, not a rule on the data. Anything writing through the API, a bulk import, or another flow bypasses it. In a real business system, invariants have to live where the data lives.

Concurrency is last-write-wins. Two people editing the same record on a busy day and one of them silently loses their change is not a hypothetical, it is a Tuesday.

Permissions do not scale down to the row. If your model needs per-record access, you break inheritance per item. Microsoft's recommended ceiling for unique permission scopes on a list is 5,000, with 50,000 as the hard supported limit, and performance degrades well before that. Real CRMs solve this with a security model. SharePoint solves it by creating an ACL per row, which is a different thing wearing the same coat.

Flows have throughput limits you will meet. A single SharePoint connection is capped at 600 calls per minute, shared across every flow using it. Daily action allowances run roughly 6,000 for standard licenses, 40,000 for premium, and 250,000 for a per-flow Process license, and a trigger plus one action counts as two. A loop over a few thousand list items burns through that faster than anyone estimates. When you hit it, the answer is buying capacity add-ons.

Flows are owned by people, not by the company. They run under an individual's connections. When that person leaves and their account is disabled, things stop, and the failure is usually discovered by a customer.

Notice that none of these are bugs. They are the correct engineering trade-offs for a shared multi-tenant platform serving hundreds of millions of users. They are just the wrong trade-offs for a system of record.

Why Business Owners Love It Anyway

I want to be fair here, because the appeal is not irrational.

It is already paid for. SharePoint and standard Power Automate come with the Microsoft 365 licenses you are already buying. There is no new line item, no new vendor, no procurement cycle, no security review. Compared to signing a contract with a new SaaS provider, the friction is roughly zero.

Nobody has to approve anything. An operations manager can build a working tracker on Thursday without asking IT, without a budget request, without a project.

Permissions and identity are already solved. Access rides on accounts that already exist. That is genuinely valuable and easy to underrate.

It feels reversible. No contract, no migration, no commitment. If it does not work, you just stop using it. That safety is a big part of why people start.

And the big one: control. You can add a column yourself. You can tweak a flow yourself. No ticket, no hourly rate, no waiting on a developer. For an owner who has been burned by a vendor before, that feels like independence.

The Part About Control Nobody Says Out Loud

Here is my read on that last one.

Control is real, but it is not free. It costs you hours. To add a column and have it actually appear in the right views, the right forms, and the right flows without breaking something, you need to understand how the pieces connect. That is a few hours of learning, minimum, and it is not a one-time cost because the platform keeps changing.

You are a business owner. Your hours are the most expensive hours in the building. So what actually happens in almost every case I have seen: after the second or third time, you stop doing it yourself and you pay someone. Which is fine, except now you are paying someone to work inside a platform that fights back.

And that is where the economics quietly invert. Early changes are cheap because you are working with the platform. Later changes are expensive because you are working around it. The same request, "can we link these two things and show a total," costs an hour in year one and two days in year three, because by then the answer involves a workaround for the lookup threshold, a flow to keep a denormalized copy in sync, and a filtered view to stay under the query limit.

At some point you are spending custom-development money to not have custom software. That is the moment worth catching.

And here is what changed recently: that crossover point arrived a lot sooner than it used to. Developers are meaningfully more productive with AI than they were two years ago. The custom build you priced out in 2022 and decided against does not cost what it cost in 2022. If you are already paying a consultant to maintain a SharePoint contraption, it is worth re-running the math. The alternative got cheaper while your workaround got more expensive.

The caveat is that "custom" only pays off if you actually own the result. You need the source code, and you need to be able to change vendors without the project dying. I wrote a whole piece on how to evaluate that: AI Made Software Cheaper and Faster. Choosing the Right Vendor Got Harder.

Why Developers Groan

This one deserves nuance, because the common complaint is overstated and the real problem is worse than the complaint.

The overstated version is "there are no proper development tools." That is not true anymore. SPFx is a real toolchain (TypeScript, React, npm, gulp) and it lives in Git and builds in a CI pipeline like any normal project. On the Power Platform side, solutions can be unpacked into source control, Dataverse now has native Git integration, and Power Platform Pipelines will promote a solution from dev to test to production with approval gates. Microsoft has invested a lot here and it shows. Power Automate also has an expression language, and you can call Office Scripts written in TypeScript from a flow. So "no scripting at all" is not accurate either.

Here is the actual problem.

The configuration surface has no first-class source-controlled representation. Your custom code is in Git. Your site structure is not: lists, columns, views, forms, permission scopes, the things your business logic actually depends on. You reconstruct it with PnP provisioning templates and PnP PowerShell, which are community-maintained tools without a Microsoft SLA, and they get you most of the way. Most of the way is a problem when the remainder is discovered in production.

Diffing a flow is not really diffing. A flow exported into a solution is JSON describing a graph. You can commit it. You cannot meaningfully review it in a pull request, and two people who edited the same flow do not get a merge. They get a mess. The practical answer is to make sure two people never edit the same flow, which is a process constraint standing in for a technical capability.

Environments cost real money and real setup. Proper dev/test/prod for Power Platform means separate environments, solution-aware flows, environment variables and connection references so nothing points at the wrong system, and Managed Environments on the targets. It is all achievable and it is all work: work that is free in a normal application, where a second environment is a config file and a database.

AI helps less here. Not zero. Copilot in the maker portal is real, and it is decent at drafting a flow. But the enormous productivity jump developers got from AI came from AI being extremely good at text-based code with millions of public examples to learn from. A graph of connector actions configured through a portal is not that. AI cannot click through a property pane for you. So the platform you chose partly because it saves developer time is now the platform where developer time is least improved by the biggest productivity shift in decades.

None of this is a showstopper. SharePoint developers exist, they are in demand, and good ones deliver. But you are paying specialist rates for a specialist to be less productive than they would be on the same problem in a normal codebase. That is worth knowing when you compare quotes.

So Do You Actually Have To Use It?

Up to you. Here is the rule I give people.

Prototype on it. Do not build your business on it.

Low-code is a genuinely excellent discovery tool. If you do not yet know how your system should work (and most people do not, they only think they do), building a rough version in SharePoint over a week or two will teach you more than any amount of requirements gathering. You find out which fields you actually use, which steps in the process are real and which are ceremony, and what people actually do when the form does not fit. That is cheap, fast, valuable learning, and it makes any subsequent custom build dramatically better and cheaper because you arrive knowing what to build.

Then, the one piece of advice that matters:

Do not fight the platform. If SharePoint does not do the thing you need, or does it badly, and your business genuinely depends on that thing, stop working around it and get a custom solution built. The workaround always looks cheaper than the rebuild. It rarely is, because you pay for the workaround every single month, forever, and the bill grows.

The signals that you are past the line, in plain terms:

• You are archiving data for performance reasons rather than business reasons
• Someone maintains a spreadsheet to reconcile two lists that should be one relationship
• A routine change request now requires explaining why it is hard
• Reporting means exporting to Excel
• One person understands the whole thing, and it is not written down anywhere

Any two of those and it is time to run the numbers.

And Yes, This Is Where I Tell You What We Do

I would rather be direct than coy about it.

The reason "just build it custom" used to be scary is the blank page. Custom meant starting from zero: months of build, a large check, and no way to see the thing until late. That fear is why people build ERPs out of lists in the first place.

Most software shops already have some foundation they reuse. We went a step further and built finished product starters: a working CRM and a working time and resource tracking system, both with the baseline functionality already in place. Not demos. Working applications we deploy into your own cloud environment, typically within a week.

That changes the comparison completely. You are not weighing "SharePoint today versus custom software in six months." You are weighing "SharePoint today versus a real application next week, fitted to how you actually work, with the source code available to you and no per-seat bill that grows every year."

We keep adding to the templates, and we keep adding new ones based on what clients ask for. If your problem is close to one of them, you are most of the way there on day one.

If any of this sounds like the conversation you need to have, including the version where the honest answer is "keep using SharePoint, you are fine," then tell us about your project. I will tell you which side of the line I think you are on. That part is free.