Jeff C. Kelly

For my money, Microsoft’s Power Platform is the best low-code/no-code development platform in terms of power and ease of use. For this post series, I will be focusing on PowerApps, primarily in its use as a platform for replacing the default SharePoint List forms with full-featured apps.

Initially, I was skeptical about yet another low-code development tool. In my experience, “low-code/no-code” meant that the functionality I needed would be spoon fed to me by the vendor piecemeal, and this would be fine as long as I stayed within the narrow confines of the tooling. The problem is that in the past, any time I needed to stray one step outside those offerings, I would be obliged to jump through so many hoops that the low-code tools became a hindrance–much more laborious than simply firing up Visual Studio and writing some C# or JavaScript. (I experienced this with K2 SmartForms ten years ago.) Low-code platforms are by necessity opinionated software, since the vendor must anticipate how you will use the visual tools. PowerApps, however, has nearly eliminated this problem, which this blog series will illustrate.

There are three types of PowerApps you can create: Canvas Apps, Model-Driven Apps, and Power Pages portals. Within Canvas Apps, you can create a standalone application, or you can use a PowerApp Form as a replacement for a SharePoint Online list form. This works in the same way that you could previously replace the built-in SharePoint forms with InfoPath Services forms. You simply go to your SharePoint List and kick off the form-replacement solution from there. (With non-SharePoint Canvas apps, you start from the PowerApps homepage.) SharePoint-form-replacement PowerApps are identical to ordinary Canvas Apps in the development/designer experience; however, in the management and deployment of your solution, SharePoint form apps are in a sense second-class citizens. This is not a terrible thing, but you need to know the limitations. And that leads us to the first”surprise” in our list.

Surprise #1: SharePoint-form apps do not appear in the Apps list in PowerApps.com.

Your ordinary PowerApps (Canvas, Model-Driven or Portal), that is, apps you create from the PowerApps homepage, all appear in the Apps list; SharePoint forms apps do not. This can be confusing for the newcomer. You create a SharePoint form PowerApp from the SharePoint List by selecting Integrate> PowerApps > Customize forms from the List toolbar, and that is the only way to access it in the future (other than bookmarking the app’s design surface in your browser). The form is tied to the List as a sort of second-class citizen, as mentioned.

Surprise #2: SharePoint-form apps cannot be exported/imported.

A knock-on effect of this subclassing is that you cannot add your SharePoint form app to a PowerApps Solution, because it does not appear in the Apps list (a Solution is the primary method of packaging and porting your Apps to different Microsoft 365 environments or tenants).

Without using a Solution, PowerApps does support exporting and importing an App into a new tenant. According to this blog post, you can export/import a SharePoint-form app by unzipping the package file and changing the Site URL, List name and List GUID, but in our experience this works only intermittently.

The upshot of this surprise and the previous one is that if you want to develop your form app in a Dev site or tenant and then promote it to a UAT or Production environment, you will likely be recreating the app by hand. You cannot even port/reuse a form to another List in the same Site!

Surprise #3: A SharePoint-form app is automatically created in the Default Environment in your tenant.

Microsoft does this, and there’s not much you can do about it. But it’s good to know.

Surprise #4: SharePoint-form apps behave differently when they are embedded directly in a SharePoint page.

Native Canvas apps created in powerapps.com are loaded directly from there, with the App GUID tacked onto the URL, like this:

https://apps.powerapps.com/play/providers/ Microsoft.PowerApps/apps/ 00000000-0000-0000-0000-0000000000

Your SharePoint-form apps, however, are injected into the native SharePoint form pages for your List, namely, NewForm.aspx, EditForm.aspx and DispForm.aspx. When SharePoint is loading these pages at a browser’s request, it checks to see if a PowerApps override is in effect, and loads the PowerApp form if it exists. This happens whether the user is currently browsing the List directly (in which case the form loads in the slide-out panel) or arriving at the List from a webpart page or other location (in which case the form is embedded in a full page with no panel).

There are a couple of implications of this difference. The first is the behaviour the user sees when leaving the form, which I will cover in the next blog post. The second is seemingly simple, but can have big implications for you as an app developer:  

‍PowerApps embedded in SharePoint pages cannot retrieve parameters from the querystring.

If your users will be using your form as a simple data-entry tool, working directly from the List itself, you may not even notice this limitation. However, if your users will be accessing your form app via hyperlinks (say, from inside an email body), and you need to pass in data values that cannot be retrieved programmatically inside the form, you will need to present users with the form outside of SharePoint, from the https://apps.powerapps.com/play URL. And this will have implications for the user experience that you will need to overcome.

In the next post in this series, I will reveal some more surprises we experienced when changing over to PowerApps development from traditional coding. Watch this space for Part 2!