The repeating rows is keeping rows in a secondary list, and keeping a connection between them using a multi-lookup column.
Since there is no possible way to perform multiple updates in a single transactions in SharePoint, saving changes to the rows and the main item cannot be completed within one call (fail all or pass all).
So, there are situation when the rows may be updated, and the main item will fail to update due to validation, network issues or browser closing/crashing.
Due to that restriction we have developed internal logic that will keep the connection between the main items and its rows, while still covering situations where:
- A user edits an item and removes a row, then cancels the item update
- A user edits an item and removes a row, then the browser closes without saving the main item
- A user edits an item and adding a new row, then cancels the item update
- A custom automation edits the main item and clears its lookup columns, but rows are not deleted
- A user removes rows, they are removed to the recycle bin and later restored from the recycle bin
- Many other edge case scenarios
Another limitation of the solution would have to consider that this is a multi-tenant cloud-based solution, and therefor cannot register delayed timed actions reliably and cost-effectively on such a large scale.
Due to those unique situations we have designed several components to maintain reliable data:
- An event handler that cleans up rows that are no longer referenced by a master item, after they have been orphaned for more than 30 minutes. (30 minutes is the timeout for forms that a user can remove a row and still save his updates.)
- A UI detection in the repeating rows column that detects rows that are associated with the current main item, but are not referenced by it - allowing the user to decide if they want to restore them or clean them up (this covers scenarios with restore from recycle bin for example).