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:
- Since this on-prem, I cannot create a view to simply limit down to the columns needed for the create/update action.
- The erratic behavior I experienced in my earlier attempts with a large list column count using a Power BI click as a trigger was if I only attempted to add one item to the list, it worked flawlessly. When I would attempt to add more than one item, it would just loop on the first item and add it over and over until I cancelled the flow
