Microsoft Forms vs SharePoint Lists vs Power Apps vs Custom Forms

Over the past year, I’ve gained a deeper understanding of how forms operate across the Microsoft ecosystem and wanted to share what I’ve learned. Forms may seem simple at first glance—a URL sent out, a “Submit” button clicked—but they form the backbone of how organizations collect and process input from users. Whether it’s students enrolling in courses, clients submitting feedback, or internal teams managing requests, forms are central to modern workflows.

Gone are the days of in-person queues and inboxes overwhelmed by scattered emails. Today, forms streamline operations, enable automation, and increase organizational efficiency. And yet, despite their ubiquity, many people still think of forms in binary terms: either quick-and-dirty tools like Microsoft Forms or Google Forms, or full-scale custom web applications built from scratch.

In reality, especially within the Microsoft ecosystem, the form-building landscape is far richer. Beyond Microsoft Forms, there are SharePoint List Forms, Power Apps backed by Dataverse, and of course the custom-built solutions—all with distinct strengths, limitations, and use cases.

This post draws on my experience leading automation and digital transformation projects at the University of Toronto. I’ll explore each of these options, compare their capabilities, and offer practical guidance for teams deciding which approach is right for them.

Microsoft Forms #

Microsoft Forms is the most lightweight option. It closely mirrors Google Forms in both functionality and design. When someone submits a form, their response is recorded in an associated Excel workbook, typically stored in OneDrive or SharePoint. Forms can be widely shared, including externally, and allow quick creation of surveys and polls. This simplicity makes it ideal for one-time data collection, quick internal surveys, and low-risk feedback forms.

However, Microsoft Forms lacks relational data, historical tracking, permissions granularity, and automation integration beyond basic Power Automate triggers. It’s a great entry point but quickly becomes limiting for more structured workflows.

SharePoint Lists #

SharePoint Lists offer a middle ground between forms and databases. A List allows users to define columns with data types, build relationships via lookups, and attach files directly to items. It’s often described as “Excel with structure”—and with good reason. Unlike Excel, SharePoint Lists support row-level permissions, field validation, and native integration with Power Automate for robust workflows.

That said, SharePoint Lists aren’t full databases. They don’t guarantee ACID compliance, versioning is limited, and they lack full relational modeling. Still, for internal workflows where users need to sign in, interact with structured data, and trigger business logic, SharePoint Lists are often a solid solution. They also maintain a better security posture than Excel or Forms, assuming appropriate permissions are configured at the site and list levels.

Third-Party Forms #

There are numerous third-party form builders on the market—many of which are cost-effective and easy to use. However, these solutions generally sit outside the Microsoft ecosystem. This can complicate authentication, security, data integration, and governance. For public-facing forms or niche use cases, these platforms might suffice. But for enterprise or academic environments with strict compliance and IT integration requirements, they may not be viable long-term options.

Power Apps and Dataverse #

For teams that need full control over data relationships, user experience, and app logic, Power Apps paired with Dataverse offers a compelling path. Dataverse acts as a proper relational database backed by Microsoft Entra ID, with built-in support for role-based access control, file storage, and field-level security.

What sets Power Apps apart is its ability to preserve app state, run complex logic, and offer dynamic, user-specific interfaces—all without writing traditional code. Apps can fetch and display PDFs, support rich-text editing, run workflows, and present customized navigation and layouts. Unlike SharePoint Lists or Forms, Power Apps are true applications—not just data collection tools. Power Apps is also billed as a code-less/low-code platform, which is very true, and the maintenance of such a system only requires one dedicated administrator. Another drawback is that starting up an entire project likely requires a more technical person who understands database normalization, relationships, and proper environment maintenance.

Of course, this comes with trade-offs. Power Apps requires more technical expertise to build and maintain. Licenses are also necessary, as the platform relies on backend compute to deliver dynamic functionality. There’s also the unknown of how much Microsoft will change licensing fees and the inability to control your own infrastructure. However, the benefits are significant: real-time telemetry, usage analytics, environment-based deployment, and even Git-based version control (for Canvas Apps). For medium to large teams, or for applications expected to scale or evolve, Power Apps and Dataverse offer enterprise-grade capabilities.

Custom-Built Forms #

Building your own form infrastructure offers the ultimate flexibility. Your team can craft a bespoke interface, design the backend architecture, and control every detail from UX to security. In practice, however, this approach is costly. It demands a development team with expertise in front-end, back-end, database management, DevOps, and cybersecurity. You’ll also need resources for accessibility testing, penetration testing, and ongoing maintenance.

In many organizations, this level of investment can easily surpass $250,000 annually, even for relatively simple applications. For instance, infrastructure costs for hosting an enterprise-level Oracle Database cost at least $1000 per month per instance and a software developer around $100k a year. The need for multiple database instances, servers, and environments grows the cost substantially. At the University of Toronto, developing a unit’s own application also means working through University governance protocols, auditing, information security risks, and much more. A developer team likely needs to be hired (full-time FTE), and getting the entire project approved can take months. Unless you’re operating at enterprise scale or supporting a mission-critical use case, it’s rarely the most efficient path—especially when modern low-code tools can meet the same needs with far less overhead.

Final Thoughts #

Choosing the right form technology depends on your project’s needs, your team’s technical capacity, and the level of security and scalability required. In my experience, Power Apps with Dataverse works well and represents the future of the forms experience. It strikes the right balance between flexibility, structure, and long-term maintainability. While it may require a steeper learning curve and upfront licensing investment, the long-term benefits in reliability, scalability, and governance make it a worthwhile choice. I see the benefits especially in internal tools and processes that aren’t necessarily customer-facing and don’t require the beautiful user experiences that full-fledged websites provide.

If your team is looking for a quick and easy form submission process, then a static-form format is still the way to go. We can quickly generate forms and users can use them immediately. I’d also argue for the use of a hybrid approach where static-rendered forms like Microsoft Forms continue to be used while other more sophisticated processes use something like Power Apps.

Finally, if teams have the need, then there are of course major benefits to deploying/creating an entire web application. One area that I didn’t discuss above is compute—owning your own infrastructure has major benefits. In addition, if an organization values opportunities for performance optimizations and scalability, then owning their own infrastructure and managing databases is better due to much higher configurability.

Also to note is that this blog only touches on Microsoft products and focuses on teams and organizations that work exclusively with Microsoft. There are of course organizations that use Google and could benefit from similar products such as Google Apps Script. In addition, there is a popular framework called n8n which can be used for individuals looking to get into this space. I just picked Microsoft because the vast majority of enterprises in Canada use Microsoft products.

At the end of the day, like all engineering, there are tradeoffs to be made.