That’s right: Single/Multi lines of text, Date and Number columns are all you need for most Power App with SharePoint projects. Before I get into why and how, let’s start with when: SharePoint predates Power Apps by nearly two decades and thus most column types not listed above should be considered legacy and are quite unnecessary and redundant because of the newer capabilities of Power Apps. There are specific reasons why you should avoid legacy column types, but they all have to do with this overarching fact: SharePoint is old.

Because of this age difference between SharePoint and Power Apps we simply don’t need the features these legacy columns provide. Power Apps has all these same features and then some. For instance, the SharePoint Lookup column type (not to be confused with the Power Apps/Power fx LookUp() function!) was the primary method to make relationships between SharePoint lists…until Power Apps came along. A Power App has this relationship natively as it can connect to both SharePoint lists at the same time, which makes the SharePoint Lookup column type obsolete.

Let’s go through each legacy SharePoint column type and why you should avoid:

Choice

Choice columns should be avoided except for a particular scenario which I’ll discuss further down. If we go under the hood and take a look at what makes a Choice column, here we go again, this is a legacy construct: The SharePoint Choice column type only exists to provide SharePoint OOTB users the ability to select multiple items from a drop-down control. Notice if you change the Choice column settings to not allow multiple selections, it still stores the Choice column as a table inside the SharePoint list record. This is because its schema is hard coded to allow multiple items, in other words instead of just storing the text a user selects, for example “lorem ipsum”, it stores the text in a persistent table in the SharePoint record: {Value: “lorem ipsum”} A single row table can also be called a record, so you could alternatively say a single-item Choice column is a record in a SharePoint record. But the table structure is always there, so if the need arises, you can flip the switch in the Choice column settings to change from single choice to multiple choice.

A Choice column that is not multi-select is way more complex than it needs to be and as a result, as you might guess, always having to deal with single-select Choice columns, a table vs. plain text, makes everything more difficult. Whether it’s Power App development, Power BI reporting, automation with Power Automate, exporting to Excel: everything is more difficult and time consuming with single-select Choice columns. There is no good reason to deal with the hassle of Choice column types except the aforementioned multiple-choice scenario and rare hybrid scenarios where users will be using both a Power App and native SharePoint forms.

So how do we replicate Choice columns? Reference another SharePoint list. It’s that simple. It might seem like extra work to go through the hassle of creating another list just to make a drop down, especially since using a Choice column and the Power App ‘create new form wizard’ will do that in a microsecond, but a little extra work up front will pay dividends in the long run. This is because your data is nice and flat and not full of tables and records and other wasteful junk. This also means reporting is easier, exporting to Excel is nice and clean, your Power Apps formulas aren’t nearly as complex, and so on.

With all that said, there are times Choice columns can be handy: For scenarios where you need to store multiple values per record, and a sub-list is either overkill or just not viable, then a multiple-select choice column that allows for custom values can be useful. This is especially common when the end result of your Power App is an export to Excel and you want to keep everything in one list. If a Power BI report is the end result, then a sub list often makes more sense.

Avoiding Choice columns is a common theme with many Power App blogs, one of the best is Warren Belz’s Practical Power Apps.

Person or Group, Lookup, Managed Metadata

These are all considered Lookup column types and SharePoint limits you to 12 of these per view. Not a huge hassle with SharePoint, but with Power Apps this becomes hard if not impossible to work around. This fact alone means you should avoid these column types. Here are some other reasons:

Just like Choice column types, the Person column type stores a record comprised of several items of metadata that you can easily store in a few single line of text columns. For instance, you can save a user’s email to a single line of text column, their display name to another single line of text column, and then add some JSON formatting to make it look identical to a Person column type with ‘show picture’. This makes the end user experience the same while keeping the data nice and flat.

The Lookup column type should never be used with a Power App. With SharePoint OOTB, Lookup columns are the only way to create a relationship between lists, but you can easily create this same relationship with a Power App and simple Single Line of Text columns. Just create an extra column for the ID of the other list item, and you’re done. That’s really all a Lookup column is doing, ‘looking up’ the data from another list via the ID of that list item. Typically, I choose another primary key instead of the list item ID, but the ID will work if there is no other relationship option.

Managed Metadata is another legacy construct that has very limited use cases with a Power App. Instructing a Power App to query a global data source, vs Managed Metadata in SharePoint, is almost always a better idea. If this is a requirement you should consider saving the MMD value into a single line of text column.

Image

This is a newer column type and I’ve not much experience with it in Power Apps. I can see where it would be handy to view images, but to save images from a Power App to the SharePoint Image column type is so complex that most often a SharePoint library or even list attachments are better options. I may change my opinion over time, but for now I’m going to say it is probably best to avoid Image column types except for read-only scenarios.

Yes/No Checkboxes – Boolean

The Yes/No (checkbox) Boolean column type doesn’t support complex filtering, so it is best to use a Single Line of Text column, with the simple text values of yes or no. Just like Choice columns, this may seem like extra work just to get a Check Box control in your app, but it is worth it in the long run, so you don’t get stuck later when the client asks for filtering Boolean columns cannot do.

Hyperlink or Picture, Currency

This hyperlink/picture construct is another compound column type, a record in your record, and should be avoided due to this complexity. Again, the original purpose of this column type was to provide links in a SharePoint OOTB list. And Currency is simply a Number column with currency formatting. With the introduction of JSON list view and column formatting, there is little reason to use either of these column types, even in a SharePoint OOTB solution.

Calculated, Task Outcome, External Data

Any calculation can be done in Power Apps, but Power Apps doesn’t really support these column types so should never be used in a Power App.

Summary

Try to use Single Line of Text for most everything, and only use Multiple when you need more than 255 characters, Number when you need to do math or sort based on number vs. text, and Date for the same sorting/filtering reason. Use other lists to store dropdown metadata for controls like dropdowns and check boxes, and only use Choice if you need to store multiple values. Keep your design simple and plan everything out before you start developing in Power Apps.

Excellent resources that expand on these topics: Warren Belz Practical Power Apps