Customizing SharePoint forms using Power Apps Vs Building standalone apps? Can I have a hybrid approach ?

[johnjohn123]

We have a development SharePoint online site >> and its lists' forms have been customized using Nintex forms. Now we are on the stage of converting the Nintex forms to Power Apps. and we have 2 approaches to follow:-

1) Customizing the SharePoint list forms using Power Apps, as follow:-

2) Build a Standalone Canvas App, and use the build-in SharePoint lists' forms as is.

but we have the following issues:-

1) If we follow the first approach >> then when we finalize the development work on the development site and we need to create the live site >> then we will have to rebuild the customized forms, as currently there is not a way to export and import the customized Power Apps forms.

2) If we follow the second approach to be able to import and export the power apps from dev to live >> then users can still interact with the SharePoint lists using the SharePoint built-in forms, so any business logic implemented inside Power Apps (like cascading drop-downs, hiding fields, make fields as disabled) can be over passed by users when they create or edit list items using SharePoint built-in forms.

so how we can fix these issues? for example is this scenario achievable:-

To build a power app standalone >> so we can Export and Import them between different sites >> then inside the standalone app to define deep linking >> and finally , to define a redirect from SharePoint list to the standalone app. So if the user click on edit link inside SharePoint list view Or click on the edit button , as follow:-

to redirect the users to the standalone power app instead of opening the built-in forms? is this approach achievable? if not then which approach of the above 2 approaches we should follow? and why?

Thanks in advance for any help.

[Pstork1]

I do not think you will be able to redirect the built-in Edit buttons in SharePoint to point to a Power App.  So personally, I would go with option #2 and then set a governance policy that prohibits users from interacting directly with the SharePoint list.  You can also do some things to make direct access to the list more difficult by hiding it, etc.  But there is no way to prevent access entirely, which is why a governance policy is necessary.  Then like all governance policies you need to train people on the policy and establish auditing to intercept any violations. Finally, if you want people to be able to access the app in the SharePoint context you can embed the app on a custom page.  This provides access to the form inside SharePoint, but maintains the business logic in an app that can be exported/imported.

[johnjohn123]

@Pstork1  thanks for the reply. But i have these 2 points on your reply, if you can advice on them more:-

1) we do not want to hide the list, as we still need users to search, filter and export the list items using the built-in SharePoint capabilities. otherwise if we chose to completely hide the list, then we can not convince our customers to have SharePoint at the first stage!

2) what type of governance policy we can have? to prevent using SharePoint built-in lists? can you advice please?

To be honest, i feel like SharePoint and Power Apps do not work together, espically for implementing enterprise apps?? and if we can not define a redirect from the SharePoint Edit/New buttons to Power Apps. then i will go with the first approach of customizing the SharePoint lists' forms, and wait for power apps to support importing/exporting these customized forms (not sure if this is within the upcoming features).. really we as software developers are left with serious troubles when using Power Apps along with SharePoint!

[Pstork1]

By governance policy I mean setting a "rules of the road" on how users interact with that SharePoint list.  Its like we agree that everyone in the US drives on the right side of the road and everyone in the UK drives on the left.  The roads don't enforce that, we do it because to do otherwise leads to accidents. There is no way to enforce it in code at this point, nor do I think there ever will be.

SharePoint and Power Apps were both designed primarily to allow easy access to no code tools for non-professional developers.  That doesn't mean they aren't valuable for professional developers also, but they weren't the target audience.  That's why SharePoint isn't a sophisticated relational database and why some of the normal tools used by professional developers aren't available in Power Apps.

[johnjohn123]

@Pstork1  yes but for the road example you can know who will break this policy.. so if someone in the UK drives on right , then you can figure him/her out.. But for modifying list items using SharePoint built-in forms Vs Power apps.. how we can know/figure-out if the update was made from SharePoint built-in forms or from power apps!! so we will end up having a policy that can not be validated and monitored !!

[Pstork1]

There are audit logs that can monitor both Power Apps and SharePoint.  I believe there are ways to keep track of where updates were made.  For example, include a hidden column that is set when the update was made in Power Apps.  When the update is made in SharePoint the column won't appear and no value will be entered.  I can easily search for records that have the wrong value in that field.  There are ways to monitor this kind of thing. But the real key is training.  User's need to be aware of the policy and why it was put in place.

[johnjohn123]

@Pstork1  do you think such an approach really work from a Design perspectives? and have you implemented such a thing before? i consider this as a bad workaround that i will stay away of it... espically if we are talking about having 60++ lists inside each of our sites (and we have 20 sites).. to be honest i am starving to know how developers all around the world have been using Power Apps with SharePoint without handling or complaining about these serious issues...

[Pstork1]

1) yes, I believe it will work

2) If you want to create a true enterprise application then use a real database like dataverse or SQL.

3) Using custom list forms isn't going to make it much better.  You'll still need to build 60+ forms in 20+ sites.  Changing the connection to point to a new list in a regular Power App is much easier than trying to do it with a custom form.

4) If you don't like the tooling available then choose a different product.  The problem is that is either expensive custom development or a pricey third party tool. That's why people continue to use Power Apps and SharePoint.

[johnjohn123]

@Pstork1 

1) yes, I believe it will work

have you done such a thing before?

2) If you want to create a true enterprise application then use a real database like dataverse or SQL.

our customers already have SharePoint licenses, they are not interested in buying extra licensing..and it is good to know that Power Apps are not suitable for enterprise applications that use SharePoint as back-end.. at the end SharePoint is capable of handling enterprise applications that have million of records

3) Using custom list forms isn't going to make it much better. You'll still need to build 60+ forms in 20+ sites. Changing the connection to point to a new list in a regular Power App is much easier than trying to do it with a custom form.

it will make our system more robust and secured (which is more important that been easy) ,,, that users can not over-pass all the business logic inside our power apps by simply creating/editing the list items using the SharePoint built-in forms..

4) If you don't like the tooling available then choose a different product. The problem is that is either expensive custom development or a pricey third party tool. That's why people continue to use Power Apps and SharePoint.

our customers already chose their technologies and they are expecting it to work for them at-least for the next 10 years... but i am start to feeling the issue... anyway i asked another question about the future plans to be able to export/import customized forms. maybe we can customize the forms and wait for this feature to be available. i am having a real issue that we are now in 2022 and we still can not export/import our work between similar sites/environments..

[Pstork1]

So your argument is basically that the customers have chosen and paid for the technology, but you don't like its feature set.  I'm not here to debate what PowerApps/SharePoint should be.  MS didn't ask me when they built it.  I'm just trying to explain what can be done. Not justify the limitations of the product.