Power Apps or Forms365 for a SharePoint List Form? A Practical Walkthrough

When the default form on a SharePoint list stops being good enough, most teams end up choosing between two paths: customise it with Power Apps, or replace it with a dedicated form tool like Forms365. Both start from the same place, the "Customize forms" option on a list, but what happens next looks nothing alike. Below is what each path actually involves, step by step, and where each one tends to show its strengths and its limits.

Building the form: Power Apps vs Forms365, step by step

1. Starting the customisation. Click Integrate > Power Apps > Customize forms in SharePoint and it generates a canvas app scoped to that list, wired up through a SharePointIntegration control. With Forms365 you install the SPFx form customizer once from the App Catalog, then open the hosted designer against the list you want to change. Neither route needs a developer. But Power Apps starts you on a blank canvas; Forms365 starts you with a form already laid out from the list's columns.

2. Designing the layout. Power Apps gives you an open canvas. Place any control anywhere, resize it freely, mix in galleries, tabs, or components pulled from elsewhere in the Power Platform. Forms365 works differently: you drag fields, sections, tabs, and accordions from a fixed library onto a responsive grid that reflows on smaller screens. You give up some layout freedom. What you get back is a form that's harder to break by accident.

3. Adding logic and validation. In Power Apps this means writing Power Fx formulas against DataCardValue controls, Visible properties, and OnChange events. It's real code. It takes real time to learn and debug. Forms365 handles the same job with declarative rules, visibleIf, requiredIf, enableIf, and when a rule can't stretch far enough, an author-facing JavaScript API (f365.*) that reads and writes field values directly. For simple logic, Forms365 is faster to set up. For logic that spans other data sources, Power Apps' formula language pulls ahead.

4. Working with folders. This is where the two tools really diverge. A Power Apps customised form does not carry folder context. If someone is sitting inside a subfolder and creates a new item through the customised form, that item lands at the root of the list instead of the folder they were in. There's no setting to fix this; the canvas app simply has no concept of folder hierarchy at save time. Any list that relies on folders for permissions or organisation needs to think this through before picking Power Apps as the form layer. Forms365 sits on top of the native SharePoint form lifecycle, so folder behaviour follows the list's normal rules without extra handling.

5. Testing on mobile. Customised Power Apps forms have a well-documented history of rendering problems inside the SharePoint mobile app. It's common enough that Microsoft support has worked cases on it directly, and the Power Apps ideas forum still carries an open request asking for customised forms to be responsive by default. Teams that have shipped these forms end up redesigning layouts, testing across several mobile clients, and accepting that some users get a worse experience than others, something the plain default SharePoint form never struggled with. Forms365's grid collapses to a single column on small screens as standard behaviour, not something patched in after complaints.

6. Publishing and maintaining it. Publish a Power Apps customised form and it goes live immediately for everyone using that list form. Changing it later means reopening the canvas app, and because the SharePointIntegration control behaves differently in Studio than it does at runtime, some properties simply aren't visible while you're editing. What you see while building isn't always what your users get. Forms365 re-reads the list schema on every load, so a column rename or a new choice option shows up without a manual republish. It also keeps a version history, so a change that goes wrong can be rolled back.

7. Deciding on data and connectors. If the form needs to write to Dataverse, call a Power Automate flow inline, or pull data from a connector that has nothing to do with SharePoint, Power Apps is the right tool. It's a full application platform, not just a form layer. Forms365 stays narrower on purpose: it customises the New, Edit, and Display forms on a SharePoint list and writes directly to that list, so any Power Automate flow already triggering off the list keeps working without extra setup.

What can go wrong

The most common mistake with Power Apps customised forms is skipping tests on folder-based workflows or mobile access before rollout. A form that works cleanly in a desktop browser can quietly break folder permissions, or simply fail to load properly for someone checking the list on their phone. Neither failure shows up until someone hits it in production. With Forms365 the risk runs the other way. Teams sometimes go in expecting Power Apps-style formula freedom or Dataverse-level integration, and hit the edge of what a rules-plus-JavaScript form model is built for. Neither tool is wrong for doing what it does. The mismatch is picking the wrong one for the job. If a form really needs to be a small application spanning several data sources, use Power Apps. If the job is making a SharePoint list's own form quicker to build, easier to keep current, and reliable on a phone without redoing the layout later, that's the gap Forms365 is built to close.