Forms, Forms, Forms

You may also view the Power Point presentation here: Forms Forms Forms.pptx

What Are My Options?

When building out forms in Microsoft 365, you have several options available. As with everything in M365 when there are several options, each solution is optimal in its own situation.

• You can build a form using Microsoft Forms.
• You can use JSON formatting to customize a SharePoint list
• You can use Power Apps to create a custom SharePoint form
• You can create a stand-alone Power App that stores its data in the Dataverse or a SharePoint list

Let’s walk through each of these options, as well as their pluses and minuses.

Microsoft Forms

Pluses:

The biggest plus of using a Microsoft form is just how easy it is to spin up a new form. Forms was originally written for the education sector and started out as an easy way for teachers to create quizzes for their students. You can create a variety of forms that include graphics and even branching.

You can share a Microsoft form externally from your organization, making it great for collecting information from people who don’t have to be logged into your tenant. You can even create a QR code to add to posters and flyers, etc.

Minuses:

This solution doesn’t scale so well; all your answers just add to one another and can only be exported in a giant Excel spreadsheet. If you have an on-going process (such as an HR form that tracks employees that are getting hired or terminated), this list will become unhelpfully large. Additionally, if you use the form for something like event registration, it’s easy to copy and paste the form (a plus) but over time, there’s not a good way to wade through all these forms in the user interface. Having hundreds of forms would just become unusable after a while.

Note: A workaround to saving data in the from is to export the data to another data source, such as the Dataverse or SharePoint using Power Automate. Note, though, that you still aren’t really solving the problem of the data being appended to one giant result set in Forms. It just sort of hides that from you.

Forms is meant to be a no-code tool, so if you want any degree of customization, you’re out of luck. What you see is what you get.

Bottom line:

Great for “quick and dirty” simple forms that will be used for a short period of time and then are deleted, and is your only easy option if you want to share a form that doesn’t require authentication.

SharePoint Form With JSON Formatting

Although it’s possible to customize your SharePoint form using a Power App (see below), that’s just one more digital asset that needs to be maintained. Microsoft has figured out that many times, the only reason people want to build a custom form is because their SharePoint list simply has a lot of fields that are hard to scroll through in the long, vertical information pane. Folks want a way to let those fields be organized and more readable. Enter JSON formatting.

Pluses:

JSON formatting allows you to:

• add headings above clusters of fields in your form.
• add HTML elements such as background colors and icons to make sections of the page stand out.
• let your fields stack horizontally on a wider form.

Minus:

• You cannot adjust any functionality of the form itself, e.g. “when user selects option A from Drop Down Menu 1, hide Drop Down Menu 2.”  JSON formatting is really meant for primarily styling.
• While working with JSON isn’t the hardest thing in the world, for some power users, just working with JSON can feel a little intimidating. Luckily Microsoft provides some good copy-and-paste guidance but still, you have to ensure users don’t totally flip over using JSON. Debugging JSON is also problematic because the only error you get is a generic one if you don’t format your JSON just right.

Bottom line:

When using this approach, the assumption is that users are already familiar with SharePoint and know how to use the “new”, “edit”, and “view” forms in SharePoint. This is a great way of dividing a large SharePoint form into a more readable format without needing to create any additional asset to be maintained other than some simple JSON markup.

SharePoint Power App Form

There are times where you want unique functionality that is only available by creating a Power App form. However, you still want users to navigate to the SharePoint list and gain the benefits available in the grouping/sorting/filtering of the data in your SharePoint list. In this case, your best option is to create a custom form using Power Apps.

Pluses:

This is your best option if you want custom functionality, such as:

• Showing or hiding fields based on field values that are selected
• Showing data from multiple data sources into a single view

Minuses:

• You are assuming that users know how to use SharePoint lists. In some cases, you may want users to just fill out a form and not care where the data is being saved. If that’s the case, you should create a stand-alone Power App (see below).
• The biggest minus is that Power Apps tied to a SharePoint list do not migrate well. I once spent hours trying to export and import a SharePoint Power App form to be used in a different location and it was fruitless, because the unique ID of the list as well as the URL of the parent site and list are embedded throughout the app. Only use this option if you know you will never need to move the app to another location (or even keep the list in the same location and just change the URL of the parent site like happened to me!) In contrast, a stand-alone Power App is easy to migrate and/or reattach to another data source.

Bottom line:

This is the best solution when you want to bring in external data or provide a customized view to a SharePoint form, and you are sure your users have access to, and know how to use, SharePoint. This is especially helpful when you want to leverage the existing functionality already available to you when using SharePoint list views.

Stand-alone Power App

A stand-alone Power App is a form that is self-contained, meaning users will only use that form to interact with the data being surfaced (as opposed to using a SharePoint list in conjunction with a form).

Pluses:

• This is a great solution when users need to submit data and you can’t assume they know how to use SharePoint, or that they even care how or where the data is stored. For example, this could be a one-page form that users fill out and submit and get a thank you message, or an app that returns lists of data that users can scroll through.
• Stand-alone Power Apps are great when you need to aggregate related data into a single app, such as “parent/child” relationships, e.g. one page to let users view available class details from a “classes” list or table, and another list of data that lets them see the classes that they have personally signed up for. (I have also surfaced outstanding and completed tasks from Planner, that are related to the item of data being displayed.)
• They can be exported and imported between Power Platform environments, and can also remap their data source easily.
• Can be stood up in a Power Apps for Teams environment if you want to share the app automatically with a Microsoft 365 group of people (i.e. team members).

Minuses:

• Is now an asset that must be owned, shared, and maintained properly. If this is tied to a data source, you have to make sure the right users who own the Power App are also aware how the data source is used, and vice versa, so someone doesn’t look at that SharePoint list or Dataverse table and not know it’s being used by your app. (I suggest using Solutions when building Power Platform components.)
• Cannot be shared with anonymous users. It is possible to share the form with external users, but they must have already been invited to your environment and authorized.
• When returning a list of data, there is no native way to provide sorting, grouping, and filtering. You must manually build drop-down menus, checkboxes, etc. to allow users to filter data, and then you must manually build queries to get the right data based on their input. The upshot is that it can become incredibly messy and time consuming to create filtered data when multiple filter criteria are in place.
• To compound the last issue, Power Apps will return a default of 500, and a maximum of 2,000 items in a single query. If you want to return more than that many items, you must make multiple calls and “glue” them together into a single data set locally in the Power App. This can also surface itself as delegation issues. I personally build my Power Apps to provide default parameters that would ever prevent that from happening, such as limiting the default view to returning whichever items the current user created/submitted, etc.

Bottom line:
Stand-alone Power Apps are the most portable solution and provide the most customizable approach available. This is also your best solution when you want to create a form or app that doesn’t require your users to know how to access the data source(s) used behind the scenes. This solution is not an optimal one for users outside your organization, however.

Conclusion

While this is certainly not an exhaustive list of how you can use Forms, SharePoint customized forms, and Power Apps to deliver forms to your users, I hope this has given you an idea of the scenarios when you would use each approach.