Matt Weston Using Power Apps to transform your SharePoint forms

Matt Weston

0 comments

We all use SharePoint for a huge number of different use cases, from storing documents to full document management, to data sources using SharePoint lists. SharePoint is an extremely versatile data source, and the out of the box list forms are excellent. But always, we want more from what we can achieve with the out of the box experience.

This is where Power Apps can step into the frame, and in this eBook companion to the Collab Summit, we will find out how.

In the Past

Transformation of SharePoint lists is something that we have been doing for over a decade, where we have needed to bring more intelligence to the forms or apply a different look and feel. But how it has been achieved has changed hugely. With previous versions of SharePoint, we could have created our own custom developed forms, but normally we would have used one of two methods:

  • SharePoint Designer
  • InfoPath

SharePoint Designer

SharePoint Designer was a product that shipped as an add on to the Microsoft Office Suite, and was an evolution of the Frontpage product, focusing more on the development of SharePoint sites rather than generic websites.

SharePoint Designer allowed us to create new forms by either creating new forms, cloning the out of the box forms, or directly editing the existing forms. Regardless of which way we did it, there was always a lot of work required to ensure that the styling was correct, that the forms worked in the way that we wanted, and then that everything wired back up to the list properly.

From personal experience, this was always a very hit and miss approach, sometimes being a great success and sometimes breaking the list outright. I cannot begin to count the number of hours that I spent trying to transform lists in this way.

The issue with the SharePoint Designer forms, though, was that the edited form was still quite limited, and unless we wrote lots of JavaScript to get the desired effect, then really there wasn’t a huge difference to the out of the box form. If we needed more, then we had to turn to another product.

InfoPath

InfoPath, for me, was never a great editing experience. This is purely personal that I found creating forms with InfoPath a lot of work, but to give it credit, it allowed some quite intelligent forms which could connect to multiple data sources, apply conditional logic within the form, and also submit data to different destinations including to web

services. In this scenario, InfoPath was ahead of its time, it just lacked the design aspect around it.

With the deprecation of InfoPath, we now need to look to the Power Platform to start creating the new interfaces for our forms.

What is supported?

The following field types are those that I consider being fully supported, i.e. you can use them immediately without any customisations:

  • Single line of text
  • Multiple lines of text
  • Number
  • Yes/No (Boolean)
  • Person
  • Date
  • Choice
  • Currency (although it is treated as a number)
  • Lookup

There are also some fields that I would deem as having partial support, i.e. those that work, but maybe need some effort to get them behaving in the way that you would want:

  • Hyperlink – this is deemed partial support as you can interact with half of the data. IN SharePoint, a hyperlink field contains a URL and the Display Text. When interacting in Power Apps, the hyperlink field will only show the URL.
  • Managed Metadata – this works quite well, allowing you to select your metadata from the Managed Metadata Service; however, it will not natively support nested terms. Instead, they all get display within one long list.

Finally, there are those that I have deemed as not being supported i.e. they either do not render correctly, or they just do not work with Power Apps:

  • Picture – this is effectively the same as the Hyperlink field; however, does not actually render as a picture.
  • Location – an intelligent lookup within SharePoint where you can enter an address and return more metadata to display in your list. This unfortunately is not exposed at all to us in Power Apps, but hopefully this will be available in the future.

With supportability in mind, we can now turn our attention to creating an app.

Power Apps as an Interface

For a long while, the only interface that we could build was to create a full canvas app to act as the primary interface for our SharePoint forms. This was made easy, as we could create our list, define all our columns, and then select Create App from the Power Apps menu.

The process of creating an app in this way is a great way of quickly getting up and running with an app as it will allow you to perform create, read, update and delete functions, however, it will always be created on a mobile canvas.

Creating forms in this way also means that we are being tied to using either the Power Apps player, or the Power Apps web part on a SharePoint page, neither of which again gives the truly integrated list customisation that we’re looking for.

We now have the ability though, to go ahead and create a list form that will replace the list form blade which appears when we create, edit, or view our list items.

Power Apps Forms as an Interface

Power Apps Forms are a fantastic way of being able to bring the capability of Power Apps directly into SharePoint, where we can modify the list items without having to leave the context of the apps. This is simple to do, as on the same Power Apps menu that we used to create the full Power App.

Creating the Form

To create the form, first, navigate to the SharePoint list, click the Power Apps button on the menu, and then select Customize Form.

Once we have created the app from SharePoint, we will still be faced with the same Power App studio that we would normally use, however, there is a small difference in the Tree view: SharePointIntegration which allows you to specify the behaviour when someone interacts with SharePoint. This gives you the option to run formulas for the specific actions:

  • OnNew – What happens when someone clicks the New button
  • OnEdit – What happens when someone edits an existing item
  • OnView – What happens when someone views an existing item
  • OnSave – What happens when someone clicks the save button
  • OnCancel – What happens when someone clicks the cancel button

Once in the Power App studio, we can then start to customise the form. You will notice that to start with, you have a single screen with a single form. I can start to customise this form by adding the controls from the toolbox, just like a full app.

Once we have made our changes, we then need to save the app, by going to File and Save, and then Publishing to SharePoint. Once our app has been published, it will then be visible to everyone who is using the list. Alternatively, we can choose to keep the app in draft, which means that we will not press publish.

Once we have published our changes, we can then return to SharePoint by clicking the link in the top left corner. Our form is now ready for us to use, so if we go and click New Item in our list, then we will be presented with our new customised list form.

The effect of orientation

Just like with our full apps, we have options for the orientation of the app which has quite a significant impact on the SharePoint list form. By default, all apps are portrait, just like a standard mobile phone canvas app.

However, we can change the orientation to landscape. When we make our form landscape, and we publish it back to SharePoint, we will see that it allows us to use a lot more of the SharePoint screen.

Having our app take up more of the real estate in this way means that we can start to include much more content and styling into our form to make it really engaging. When developing forms in this way, I find that setting the width of the key containers to App.DesignWidth helps my controls to autoformat based on the orientation that I select.

Different Forms for Different Actions

Using Power Apps as our list form gives us the option to completely customise each type of form, so we can have different forms for View, New, and Edit. This is particularly useful if you want specific fields to be shown in different forms, or to apply different formatting based on the form that is being used. So, for example, we can have a view form that is going to present information in one way, a new form that is going to show some fields, and an edit form that is going to show other fields.

Earlier, we said that there was only a single screen with a single form in the app, so we can start to add functionality by adding new screens. Within the following screenshots,

the default “FormScreen1” has been renamed to “New Screen” and SharePointForm1

has been renamed to frmNewEntry.

The first thing we can do is create two new screens for Edit and for View, so we can duplicate our existing screen by clicking on the ellipsis (…) and selecting duplicate screen. We can then rename them in line with their purpose e.g. “Edit Screen” and “frmEditEntry” etc.

Each screen can then be customised independently. However, when we load our app, the first screen and form will load by default, so we will never actually get to the other screens unless we tell the app that it needs to navigate.

This is where our OnNew, OnEdit and OnView events are used, as for each of these we can specify a formula to direct the app to the relevant screen. So, we need to select SharePointIntegration in the tree view, and then enter the Navigate(screen, transition) formula. We also need to update the form instance that the default formula refers to,

e.g. you will see EditForm(form name), which will need to be updated to the form on the relevant screen.

You will also need to ensure that you are putting navigate options for each event, even if one of them is the default because your app will need to know what to do if you click on edit, but then click on new.

Once we have customised each of our forms to give us the functionality that we want, we need to then tell the app what to do when the user presses the save button. When we return to the SharePointIntegration and select OnSave, we can see that there is a SubmitForm formula in there by default, which is submitting our first form. As we now have multiple forms, we need the app to understand which form it should be submitting based on whether the user is adding a new entry or editing an existing one.

In this case, we need to add a global variable to our OnEdit and OnNew events, which we can use to determine which form we need to submit when saving.

With this global variable being set, we can then use it within our OnSave formula to define exactly which form should be written back to SharePoint. There are two ways in which we can branch our logic, either using the IF statement, where we can test our variable for one value and if it does not match then we can do the other. Alternatively, which is the way that I prefer to work, is to use the SWITCH statement which means that we can have multiple legs of logic all a single comparison.

With this method, if we decide to have different Edit forms for different users, as an example, then we can handle lots of legs in a single statement.

Now that we have configured the forms, we have configured the app to show the correct form for the action, and also configured the correct save action. We are now in a position to publish our app and begin using it as our new interface for SharePoint.

When creating a new item:

When editing an existing item:

When viewing an existing item:

Retracting the form

At any point, we can revert to the out of the box list form from the list settings screen. This is ideal if you are simply testing the form against your list within the SharePoint experience, or if you legitimately need to roll back.

To revert back to the out-of-the-box form, simply navigate to your list, and open the List Settings by navigating to the cog in the top right corner of the screen, and from your classic looking settings page select Form Settings.

This form settings screen will allow you to perform a number of actions:

  • Use the default SharePoint form
  • Use a custom form created in Power Apps (requires new list experience) – this will change the list back to using the customised Power App as the list form

When you are using the default SharePoint form, it will also give you the option to delete the Power App form. If you ever need to remove it completely, then ensure that you have first all selected the SharePoint form, and then select Delete custom form.

Finally…

Throughout this eBook, we have focused on the use of Power Apps to provide us with a customised list form experience that allows us to utilise the power of the Power Platform, pulling data from different services to give our users exactly what they need. This is a huge step forward in terms of the technology, moving from SharePoint Design and InfoPath to the actual development practice, putting this into the hands of the citizen developers.

We have looked at the data type support in Power Apps, with Power Apps supporting most of the data types offered by SharePoint, but remember that Managed Metadata and Hyperlinks would only be classed as partially supported, while the location data type is not supported.

Our apps can be created with a portrait orientation, or if we want our form blade to take up more of the screen, then we can switch them to landscape so that we can have more real estate to be creative with the way that we present and interact with our data.

Finally, if we ever need to, our apps can be withdrawn from the Form Settings within the list or library settings screen, where we can either revert to a previous version or delete it completely after setting our form back to the SharePoint default form.

0000-00-00 00:00:00


Leave a Reply

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}