Four hundred messy rows, fixed in one reviewed pass
A companion reads every row and every column name, proposes the normalization, and runs it as a single bulk write you approve. Deletes stop and name exactly what disappears.
The vendor tracker started at twenty rows and became four hundred. Half the Status values are freetext and the owner column mixes names and emails. Fixing that in a web grid is an afternoon nobody volunteers for.
Microsoft Lists is a native integration with twenty tools behind it: find the site, list its lists, create or delete a list, manage columns, read and write rows singly or in bulk, and walk or restore a row’s version history.
| Job | The Lists web app | A Strawberry companion |
|---|---|---|
| Fix 400 inconsistent rows | An afternoon of grid editing | One reviewed bulk upsert on an indexed key |
| Concurrent edits | Last save wins | eTag check: conflicting writes fail loudly |
| Recover from a bad change | Version history, per row, by hand | Version list, read, restore; gated as writes |
| Views and attachments | Full support | Done in the Lists app |
Why your list updates hit nothing
Lists keeps two names for every column: the label you see, and the internal API name underneath. Writes accept only the internal one. So a companion resolves the site, lists the lists and inspects the columns before it writes. Skip that step and an update lands on nothing.
Concurrency gets the same treatment. Before updating or deleting a row it can read the row and pass its eTag, so a write that raced a colleague fails loudly instead of overwriting them. So you can run this against a shared tracker in the middle of the workday.
What does bulk work look like here?
Two dedicated tools: bulk mutate and bulk upsert.
Upsert fixes the vendor tracker: match rows on a key column, update the ones that exist, create the ones that do not. The key column must be indexed and enforce unique values, and cursors page through, so four hundred rows are walked completely rather than sampled.
So the pass is: read the whole list, propose the normalization with every Status mapped to a real choice and every owner resolved to a person, and run it as one reviewed bulk write. Same shape as CRM data entry cleanup, pointed at SharePoint, with Teams next door.
What happens when something goes wrong?
Version history is on the tool surface: list a row’s versions, read one, restore one.
A bulk write that turned out wrong is recoverable row by row, and the restore is a gated write like any other.
Deletes are graded accordingly. Deleting a row, a column or an entire list is flagged destructive and stops on an approval card that names exactly what is about to disappear, and the connector’s own guidance says to verify a list’s display name before deleting it.
What stays in the Lists app
It is a data surface: sites, lists, columns, rows, versions.
The filtered views your team bookmarked stay exactly where they were left, while a companion keeps the rows underneath them true.
Item attachments, sharing and permissions changes are done in the Lists app. Creating or deleting a list needs a broader SharePoint grant than editing rows, so an organization can allow the everyday writes and hold back the structural ones. Outside Microsoft, Airtable covers the same ground and the operations pattern holds.
Experience Strawberry for free
DownloadTrusted by fast-growing companies worldwide
Frequently asked questions
Strawberry is free to download and includes AI credits to start. Paid plans begin at $20/month. See pricing. · Reviewed · Canonical facts for AI agents