SharePoint/PowerApp Choice Glitch When Swapping From Single-Choice to Multiple-Select (vice-versa)

[tommyly]

I wanted to report a glitch that I observed recently. Trying to explain it from scratch is a bit confusing so I'll list the steps I took:

• I created a SharePoint Online list with a Choice field (e.g. HowAreYouFeeling; options are "Happy, Sad, Meh"; default behavior is single-select)
• I create a customized SharePoint Online form, which is--for all intents and purposes--a PowerApps form
• Within the default-created PowerApps form object, I notice that the field HowAreYouFeeling is correctly defaulted to a single-select comboBox. Its Items property is correctly set to "Choices(myList.HowAreYouFeeling)". I am able to correctly select a single item from it (e.g. "Happy")

So far everything is working correctly. But here's the twist: I decide... I want the user to be able to select more than one emotion (e.g. people can now be "Happy" and "Meh" at the same time).

• I go to SharePoint Online and edit column HowAreYouFeeling. I change the setting from single-item to multiple-select
• I go back to PowerApps and refresh my datasource
• I switch the HowAreYouFeeling comboBox from single-select to multi-select
• I now have a red error that says something to the effect of: "Expecting a record, receiving an incompatible table value". I presume it is saying that because somewhere in the PowerApps session, there is some validation that still thinks its a single-record data-type.

At this point, I try to resolve the issue. I try 4 things:

1. I deselect the HowAreYouFeeling column from my PowerApps form. Refresh the datasource. Reselect the column. The error persists.
2. I go to SharePoint and delete the HowAreYouFeeling column. Re-add it. Refresh the datasource. The error persists.
3. I close the PowerApps editor session and reopen it. Refresh the datasource. The error persists.
4. I delete the HowAreYouFeeling column. Refresh the datasource (the HowAreYouFeeling column disappears from the PowerApp form's selectable choices). I re-add the HowAreYouFeeling column in SharePoint Online. I refresh the datasource in PowerApps. The HowAreYouFeeling column appears as a selectable column. The error goes away.

While I've managed to resolve the issue in a roundabout way using step #4, I couldn't help but think... what if I had hundreds of records at the time I decided to go from single- to multiple-select? I would have to go in and fat-finger all the records back in after deleting the column.

Is there an easier way to get around this?

[Drrickryp]

Hi @tommyly,

Please be aware that in Sharepoint, complex field types like Choice, Lookup and Person columns violate one of the fundamental relational database principles, that of each cell in a table containing a single piece of data, also known as 1NF or 1st Normal form.  IMHO, this is the reason why Powerapps developers have so much trouble trying to work around what I consider a flawed table. It is better to use a separate list and to have a Foreign key in that table that is the Primary key of the second table.  Trying to represent what is a one-to -many relationship in a single table will inevitably lead to the problems that you have encountered.  Please review the following reference for a good idea of database design principles.  It will explain a lot of the problems we encounter in these forums.

https://support.office.com/en-us/article/database-design-basics-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5  

[tommyly]

 @Drrickryp

Yes, I'm aware of database normalization. Lacking Azure SQL license, I started building many of my apps based off of SharePoint lists. I'm sure many other people are in a similar situation. SharePoint, unfortunately, is very limited when it comes to structuring and querying data. For example, if I started creating many-to-many junction tables for every multiple-value field (to be normalized), trying to create a report would require filtering off of 4, 5, or even a dozen primary and junction tables. And then have to deal with managing delegation threshold not only in my primary tables, but also in my junction tables. SharePoint just isn't built to query data like a real database. Fortunately, PowerApps has a pretty dynamic and efficient way of delimiting and splitting multiple values in a text field.

So while I agree with you that data should ideally be normalized, it's just not feasible with SharePoint. That said, I would never build a large database in SharePoint. Many SharePoint-based apps are simply to track and manage data for small projects and tasks anyhow. Anything larger than that should require an application project, developer team, a real database (and hopefully proper, normalized database design).

And the problems that I'm encountering have nothing to do with data normalization. It has to do with PowerApps's inability to update its meta information about the SharePoint Online datatype. For example:

If you load a dataSource with field-column 'x' as an integer and then later change it to text (has nothing to do with data normalization), PowerApps does not receive that bit of instruction. You can refresh it a dozen times in several different ways (e.g. refresh data source, refresh form, restart program, restart PowerApps, restart browser, restart your computer, etc.) and it won't know a change has occurred. And since it doesn't know that the column has changed, it won't let you put text into the field (because text violates the number format). If you give it a number, PowerApps will allow it, but SharePoint will throw an error, and then PowerApps, at the behest of SharePoint, throws you that error. So you now have an error if you do, error if you don't.

[Anonymous]

Adding @anees to assisit with the question? 

@Anonymous

[PhilD]

Hello.

I just want to chime in that I have experienced this problem many, many times and just assumed there was nothing that could be done about it. It would be great if this could be fixed though as it really causes a nightmare when your design changes for some reason.

[Drrickryp]

@PhilD, and @tommyly

If you design your tables properly according to sound database principles you won’t have these issues.

[tommyly]

---

@Drrickryp wrote:

@PhilD, and @tommyly

If you design your tables properly according to sound database principles you won’t have these issues.

---

I agree with you... that sound database principles is best practice and functionally sound. The problem is not about sound principles. The problem and the original post is about a very specific functional issue.

1. When a column is deleted in SharePoint, a refresh will sync SharePoint and PowerApps with the changes (Works as intended).
2. When a column is renamed in SharePoint, a refresh will sync SharePoint and PowerApp with the changes (Works as intended).
3. When a column is added in in SharePoint, a refresh will sync SharePoint and PowerApps with the changes (Works as intended).
4. When a column name is modified in SharePoint, a refresh will sync SharePoint and PowerApps with the changes (Works as intended).
5. When a column's meta information is modified in SharePoint (e.g. data type, length of text, max/min numbers, etc.), NOTHING will sync SharePoint and PowerApps with the changes (Most likely not as intended).

Once you do #5, which has absolutely nothing to do with data normalization, PowerApps and SharePoint become like two, old, bickering spouses.

PowerApps: "You said it was a SHORT TEXT!"

SharePoint: "It's a LONG TEXT!!!"

PowerApps: "QUIT CHANGING YOUR MIND!!!"

SharePoint: "I'll change your face!"

It would hypothetically take me one good afternoon to normalize my data. But that won't fix problem #5. Problem #5 is not a data architecture problem. It's a SharePoint-PowerApps relationship problem.