Form data fields not saving

[duncanp]

Hi

I've got a PowerApps form linked to a SharePoint list. All the data cards are custom ones, but we've bound the controls as they should be so that they should populate from the list on load, and save back on submit.

However, while all fields appear to load successfully (i.e. we can access the data card default value), some fields save back to the list and others don't. We've established that the data cards themselves are the issue. We've gone as far as entering a text string in the Update property of the data card. For problem cards, these values don't get written back to the list.

I've exported the app and dug into the json for the form in question and I can see this difference. On cards that work, the json for the ControlPropertyState of the data card looks like this:

{
   "InvariantPropertyName": "DataField",
   "AutoRuleBindingEnabled": true,
   "AutoRuleBindingString": "",
   "NameMapSourceSchema": "?",
   "IsLockable": true,
   "AFDDataSourceName": ""
}

However on the ones that don't, it looks like this:

{
   "InvariantPropertyName": "DataField",
   "AutoRuleBindingEnabled": false,
   "AutoRuleBindingString": "\"SharePointFieldName\"",
   "NameMapSourceSchema": "?",
   "IsLockable": true,
   "AFDDataSourceName": ""
}

Removing the data card and re-adding creates cards with AutoRuleBindingEnabled true, and those re-added cards then save correctly.

I can't see any option other than to go through the cards, removing and re-adding them, but I'd be interested to know how this has occurred in the first place, as I'm concerned it might happen again at some random point in the future. If anyone can shed any light on this I'd be very grateful.

Duncan

[WarrenBelz]

Hi @duncanp ,

Firstly, an interesting related post on this here.

I have had "rogue" cards before not updating and have simply deleted and replaced them. I have never had one "re-offend", although that is only my experience.

Please click Accept as solution if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider giving it Thumbs Up.

[v-yutliu-msft]

Hi @duncanp ,

Do you mean that your form could not be updated successfully to sharepoint list?

Could you show me more details about the unsuccessful fields?

1)field data type

2)datacard Update

3)the control that is used to update the field

3)the control's key propertites, like Text,Default,DefaultSelectedItems,Items,....

4)the form's key propertites, like Item,Mode,....

You need to make sure the data that you update is the same data type as the field.

Or else, you can not update successfully.

Best regards,

[duncanp]

Hi @v-yutliu-msft 

Yes, the form is not updating back to the list. The SharePoint field types are single line text fields, and we have tried updating them from textbox controls, combo boxes and even by simply putting text into the Update property of the data card itself. Nothing works once the card gets into this state. As I say, it's not a problem with the controls or the data types, as creating a new card for the same field works fine. Even copying in the control for the broken card into the new card and using that to update the fields works fine. So it's definitely not the control, it's not the data type and it's not the list. The problem is the card itself and is related to something within its settings that we cannot control through the PowerApps interface.

However, it's impossible to replicate this issue, or know what could have caused it. I was hoping it was something that someone was aware of and has either been fixed or is under investigation.

Best regards,

Duncan

[duncanp]

Hi @WarrenBelz 

Yes, I'd seen that link and I've actually had that same issue on another app! There's clearly something going on behind the scenes somewhere, but I'm at a loss as to know what it is.

Thanks for the feedback though.

Duncan

[duncanp]

Tangentially to this, I now no longer use forms when developing new apps, unless it's for something very quick and easy. In addition to the sort of issue described in this post, I find them difficult to style, impossible to lay out reliably in anything other than a simple column and generally prone to idiosyncrasies! I prefer using individual controls in containers to control layout, and using Patch statements to perform any updates.

Duncan

[v-yutliu-msft · Accepted solution]

Hi @duncanp ,

Ok, I will report this bug to our product team. If there's any reply, I will leave message here.

If you have any problems about Patch, you've welcome to post your issue in this forum.😀

Best regards,

[duncanp]

Thank you @v-yutliu-msft . If anyone from the product team needs any more information, or would like a copy of the app in question, just let me know.

I've not had any major issues with Patch so far touch wood, but thank you!

Duncan

[christianh2o]

I had this same issue. I saved my data last night, and it told me my information saved. When I tried to load it today, it said the last time it was saved was 2:43 yesterday afternoon. Just looked like a total joke to my bosses after bragging about all the progress I had made. I looked at previous versions as well and apparently that was the last one. Nightmare. 

[joergisageek]

Just to add some insight here in case someone has a similar issue. I have a canvas app with SQL Server as data source. Later we decided to move the data to SharePoint and simply switched the source. 

After that the Gallery works and I can pull data, but Submitform doesn't work (saves nothing). Re-adding the fields works indeed, but on huge forms it's a pain, especially if heavy formatting is already done.

I compared the Datafield property and found that the SharePoint source requires the internal field names. If you edit a field in SharePoint the URL looks like this:

https://xxx.sharepoint.com/_layouts/15/FldEdit.aspx?List=<guid>&Field=field%5F21

Despite the display name the internal name is probably something like "field_21". That happens if you add fields in modern UI with the "Add column" feature on top of the list view. If you add fields the traditional way the field name equals the display name mostly.

However, the PowerApps editor doesn't understand that (from perspective of IntelliSense) and offers the display name. If you re-add the field from menu it uses indeed the internal name. So in case the binding doesn't work you may replace

ThisItem.'Some Nice Display Name'

with 

"field_xx"

even if the editor suggests differently. The good thing here and probably the reason for this behavior is, that users can change the field names in SharePoint at any time and the internal names remain unchanged. If PowerApp would use the display names, it would break the form any time users changing names. So I'd call it a feature, then.

Regarding the property

AutoRuleBindingEnabled

I guess that the binding becomes active if the field name is right. At least all my forms start saving immediately after setting the internal name and the value in the JSON goes to "true" automatically (it must, as it's not editable in the editor).

Unfortunately there is no way to know the proper names apart from careful testing.