Scenario: I am using Power Automate to send notifications from a process list on an on-premise SharePoint site, and documenting the results of the flow to a Notification History list on the same site. Many reasons why I am doing this that I do not need to go into here, just take it as the requirement. There will be over 80 notifications for the process, and the intent would be to write the results of a notification run to a distinct column in the Notification History list. So basically 81 columns - 1 for the ID from the actual process list, and one status column for each notification workflow where I would write something like "Sent on 12/31/2023".
In the past, I had a similar action step where I was Creating/Updating items on a SharePoint 2019 list from Power BI data and was unable to use the traditional Create Item/Update Item action because the list had too many columns and would behave erratically. Instead, I used the "Send an http request to SharePoint" action, which runs extremely well, but is more tedious to configure.
Since I have the opportunity to control the creation of the Notification History list, I want to go in with the knowledge that the traditional Create/Update Item actions will work on a list with that many columns PRIOR to building out the workflows. If I need to have more than 1 history list, I would prefer to know that upfront.
Does anyone know the max number of columns those actions can support before behaving erratically? Thanks!!
Notes:
Thanks for the information. I went ahead and entered the max number of columns for the process, and plan to test the Create/Update. If that fails, I will split as you suggested.
Appreciate the prompt reply!
The erratic behavior you observed with the traditional Create Item/Update Item actions is a known issue when dealing with lists that have a high column count. While there is no officially documented maximum number of columns for these actions, practical experience suggest that issues often arise when lists exceed around 50-60 columns.
As you mentioned, using "Send an HTTP request to SharePoint" action tends to be more reliable for large lists. Although it requires more configuration, it allows for precise control over the operations and can handle complex lists better than the standard actions. You might have to bear the pain once to set it properly.
You could also consider splitting your Notification History list into multiple smaller lists, each handling a subset of notifications.