Powerapp doesn't write multiple enteries from Person or Group to SharePoint list?

[FreddieV]

I have a PowerApp created from a SharePoint list. The Powerapp uses a gallery to search for entries in the list and then opens an entry in a form that is then edited (some fields are filled in, some aren't).

I have a person or group column that allows multiple values to be entered and noticed that the PowerApp does not write any of the names to the SharePoint list.

I should note that in order to make the person or group field in PowerApps search for Guest accounts as well as licensed accounts on the tenant I changed its data source (Items) property to use the Office 365 Users connector, so perhaps that messed something up? 

For the datacard, the Update value is:

DataCardValue27.SelectedItems

And for the data card value the Items proerty is:

Office365Users.SearchUser({searchTerm: DataCardValue27.SearchText})

When the form is submitted, it uses a SubmitForm to update the SharePoint list record/entry.

[StalinPonnusamy]

Hi @FreddieV 

Yes, the Person items (office365) property changed the behavior. To fix this, please set the Update property of the card to

ForAll(
    PersonCombo.SelectedItems As Source,
    {
        Claims: "i:0#.f|membership|" & Lower(Source.Mail),
        Department: "",
        DisplayName: Lower(Source.DisplayName),
        Email: Lower(Source.Mail),
        JobTitle: "",
        Picture: ""
    }
)

Thanks,
Stalin - Learn To Illuminate

[RandyHayes]

@FreddieV 

You are trying to submit Office 365 User records to a SharePoint list that expects SharePoint User records - they are both vastly different.

Consider changing your Update Property to:

ForAll(DataCardValue27.SelectedItems,
  { 
    Claims:"i:0#.f|membership|" & Lower(Mail), 
   Department:"", 
   DisplayName: DisplayName, 
   Email: Mail, 
   JobTitle: "", 
   Picture: ""
  }
)

This will produce a table of SharePoint users for the submit that will work properly.

Also, consider changing your Items Property from using SearchUser to SearchUserV2 as the first is now deprecated.

I hope this is helpful for you.

[FreddieV]

@RandyHayes 

Thanks for that. Going forward, to avoid having to do that ForAll, would it be better to just use a Single Line of Text and then just write the Office 365 Data from PowerApps to that column?

It was very helpful and useful!

[RandyHayes]

@FreddieV 

Well, they are two completely different types of columns obviously.  So, if you don't need the column to be a person column, then a text column is fine - but keep in mind, you will only be storing one of the text properties of your 365 User record (i.e. Email, DisplayName, etc).  

You need to consider the "going forward" part.  If you bring up a record again to edit/review, how would you connect to the real user?  Typically, you would want to store the email address of the user in the text column.  That way you can use that to get the 365 User profile information.  If you use the Display Name, then you can have trouble with it (i.e. you might have two people with the same name, but you cannot have two accounts with the same email).

So, you just need to decide on that factor.

The ForAll is not a problem and is doing exactly what it was designed to do - return a table of records based on whatever you want.

In this case, because you switched the Items from the Choices function on the column (which would have returned SharePoint user records) to using the SearchUser function (which returns 365 Users), then you just needed to reshape the data for the proper record type.  Again, that is what ForAll is all about!

[FreddieV]

@RandyHayes 

One caveat to this is that, as you say the O365 User record and the SharePoint User Record are vastly different. Obviously, the table converts the values from O365 User Records to SharePoint User Records. However, if you were to then go back and re-pull this record/row from SharePoint to update something (else), it won't then submit, especially if required as the data type will have changed, so it will need to be re-selected. Doe some of these fields, the user can select like 20 names. They wouldn't want to re-select 20 names that they can see are already there.

I know this wasn't mentioned to begin with, but it's something I found during testing.