PowerApps Design Approach for Multiple Forms (19 Request Types) – Best Practice Guidance Needed

(2) Share

Report

Posted on by Vaish123

136

Hi All,

Can someone suggest the best approach for the below requirement.

There are 19 different Finance Form requirements. I initially designed to create 19 separate SharePoint lists for different finance form requests and front end using SharePoint forms as per client request, but later realized this would require maintaining 19 different Power Automate flows, which is not ideal.

To simplify, I moved to a single SharePoint list approach and built a PowerApps Canvas app. The current created prototype has a home screen with 19 buttons, each representing a different request type, which then navigates to a single screen which contains 19 forms, based on button click, respective form will get visible.
However, the challenge is that each of the 19 request types has largely different field requirements, with only a small number of common columns across all forms.
We are still evaluating the best design approach in PowerApps:

A single create new request screen with single form that changes based on request type,
19 separate screens each with its own form,
Etc.

What would be the recommended architecture or best practice for this scenario in terms of maintainability

Screenshot 2026-0...

Your file is currently under scan for potential threats. Please wait while we review it for any viruses or malicious content.

Categories:

Building Power Apps

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Valantis 6,735 on at

Like
a
(3)

Report
Copy link

Link copied!

Hi @Vaish123,

With 19 largely different forms, the single screen with 19 hidden/visible form sections approach you already built will become a maintenance nightmare fast. Every form change means navigating a bloated screen with hundreds of controls.

The recommended architecture for your scenario:
1. Single SharePoint list with a RequestType column and then a set of common columns (submitter, date, status, requestor etc.) plus a large JSON or multi-line text column to store form-specific data. This keeps your data model clean and your flows manageable.

2. In Power Apps, use Components (Power Apps component library) to build each of the 19 form layouts as a reusable component. This keeps each form isolated and maintainable independently without 19 separate screens.

3. One form screen that loads the correct component based on the request type selected. Use a variable to switch which component is visible. This is cleaner than 19 screens and more maintainable than 19 hidden form sections on one screen.

4. For Power Automate, a single flow with a Switch action on RequestType handles all 19 types. Each branch sends the right email/creates the right approval chain. One flow to maintain, not 19.

The JSON column approach for form-specific fields (option 1) is the most scalable long-term since you don't need to add SharePoint columns every time a form changes. The downside is querying specific fields in filtered views becomes harder. If reporting on individual fields is important, a wider SharePoint list with all columns (most blank per row) is simpler to work with in Power BI or list views.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Suggested answer

Haque 3,653 on at

Like
a
(3)

Report
Copy link

Link copied!
Hi @Vaish123,

19 different forms where field varies based on 19 request type and very less fields are common - leads to do a reasearch.

Priamrily you have comeback from 19 list and 19 power automate stuff which is a great decision. I would add if you could identify some common fields for all request type - go for one list with all common columns plus a flexible JSON (Dataverse) or multi-line text column to store request-type-specific data - this is DB/data serouce level.

For the UI part - for all common fields you can gor for PowerApps component and rest of the field should vary based on request type.

I would also suggest to browse some samples if it matches for your case:

Galleries | Find videos, samples and templates

Power Apps Samples

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(2)

Report
Copy link

Link copied!
Your requirement (19 finance form types with mostly different fields) is a classic case where a single flat model becomes unmaintainable quickly. The key decision is not screens vs forms—it is data design first, UI second.

Best architecture: Hybrid model with grouped child tables + 4–6 Power Apps screens + 1 main flow

Consider below :

Avoid using 19 SharePoint lists or one oversized list with many optional columns—both become hard to maintain.

Best practice is a hybrid model:

One master (header) list/table for common fields like Request Type, Status, Created By, etc.

Multiple child lists/tables grouped by business domain (not 19; usually ~4–6 groups) for form-specific fields.

In Power Apps:

Keep a home screen with 19 request buttons

Navigate to 4–6 dedicated screens (group-based, not per form)

Each screen uses a clean, single form tied to its child data source

In Power Automate:

Replace 19 flows with 1 main flow (or a few grouped flows) using a switch on Request Type.

Design around a parent–child data model with grouped forms, not 19 separate solutions or one overly complex form. This gives the best balance of maintainability, scalability, and simplicity.

Was this reply helpful? Yes No
WarrenBelz 155,838 Most Valuable Professional on at

Like
a
(2)

Report
Copy link

Link copied!
Hi @Vaish123,

I will share another idea (although 19 is probably a bit over the top for this) - I have several prod apps with different requirements for different components. I use one Form and buttons (actually displayed in a Gallery, but I can get to that if required). Each button sets a Variable (I use varShow) which determines with Data Cards are visible for a particular function - example the Visible of one section is
varShow = "Measure"

which displays the fields for some measurements. One important requirement here is that if you really need to keep each line to one section only as cards do not "wrap" back to fill missing spaces on the line above.

You might consider a hybrid version (4-5 forms and fit a manageable amount of cards on each)

Please ✅ Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider answering Yes to Was this reply helpful? or give it a Like ♥
Visit my blog Practical Power Apps LinkedIn

Was this reply helpful? Yes No