While everyone was busy arguing about portals, pages, and customization, something else was getting real work done without much noise.

SharePoint lists, now branded as Microsoft Lists.

They were never exciting. They were never trendy. And that is exactly why they worked.

Lists have always been about structure. Rows. Columns. Views. Predictable behavior. They did not pretend to be something they were not, and over time, they quietly replaced a surprising number of “apps” across organizations.

Let’s be clear about one thing up front. Lists are not a relational database. They never were. They never will be. And that is fine.

For years, I still used them as the poor person’s SQL. I built entire solutions on top of lists. Tracking systems. Intake forms. Status dashboards. And yes, I fully realize the contradiction. They are not a database, but they solved problems fast, cheaply, and reliably when the alternative was nothing or something far more complex.

Modern lists changed the game without changing the mental model. View formatting and list formatting made younger me unreasonably happy with the possibilities. Conditional colors. Status indicators. Small visual cues that made data easier to scan without turning lists into a design experiment gone wrong. Microsoft continues to evolve this space, as outlined in its documentation on list and view formatting.

Forms, lists, and a small sprinkle of Power Automate turned out to be a match made in heaven. No heavy frameworks. No custom code required. Just structured data triggering predictable actions. Microsoft has leaned into this integration for years, and it shows in how naturally lists work with Power Automate and SharePoint.

Microsoft Lists as a standalone app never really took off around the places I’ve worked at. Competitors came and went, each promising the next big productivity breakthrough. Lists just stayed where they were, embedded in SharePoint, Teams, and the daily flow of work. Much like SharePoint itself, they survived by being useful, not flashy.

Here is a slightly controversial opinion. Lists are far more fun, and far less messy, without attachments.

Attachments blur responsibility, storage, and ownership. Documents belong in document libraries, where versioning, permissions, and retention actually work. Lists shine when they focus on metadata and state, not file storage. This connects directly to Day 3, SharePoint is a document library platform first, where the separation between structured data and documents really matters.

Lists also quietly introduced me to content types in a way that finally made sense. Reusable structure. Consistent fields. Predictable behavior across sites. Long before I appreciated content types in libraries, lists sold me on the concept. Microsoft’s guidance on content types in SharePoint still reflects that original strength.

That said, lists are not magic. Item limits are still a real consideration. Large lists require planning, indexing, and realistic expectations. Microsoft documents these constraints clearly in its guidance on managing large lists and libraries, and ignoring them is still one of the fastest ways to turn a good solution into a slow one.

The reason lists succeeded where many custom apps failed is simple. They respected how people already think. Tables, filters, statuses, and simple workflows are familiar. That mindset shift mirrors what I wrote about in Day 12, The day I stopped fighting SharePoint users.

Lists also avoided a trap I fell into more than once over the years. Over-customization. No fragile frameworks. No clever hacks that aged badly. That lesson came at a cost, and I wrote about it in Day 13, The hidden tax of over customizing SharePoint.

The most impactful tools in Microsoft 365 were not the loudest ones. They were the ones that quietly solved problems without demanding attention.

SharePoint lists replaced half your apps not because they were perfect, but because they were good enough, understandable, and dependable. And sometimes, that is exactly what work needs.

---

This post is part of my 25 days of SharePoint series, created to celebrate SharePoint’s 25th anniversary and lead up to the SharePoint at 25 digital event on March 2.

Each post reflects on what actually made SharePoint last 25 years, the wins, the mistakes, and the lessons learned from building, breaking, and rebuilding it in real organizations.

You can find all posts in this series here.

If there’s a topic you think I should cover next, a SharePoint mistake you keep seeing, or a question no one ever answers straight, leave a comment. This series is shaped by real experiences, not marketing slides.