Two-way sync with SharePoint

SPSync reads SharePoint Online lists and library metadata through Microsoft Graph and writes them into a database you own. It does a full load first and then a delta every few minutes. We have tested it to 10,000 items on a live tenant and to 1,000,000 on a synthetic Graph. There is no code path in SPSync that writes to SharePoint, and the answers on our security page depend on that. If you edit a row in the database copy, the edit stays in the database and SharePoint never sees it.

How write-back to SharePoint is designed

The design starts from the ways a write to a list goes wrong. Two people change the same item, or an app sends a value the column will not accept. So writing is opt-in per list and per column. A list you have not enabled stays read-only, and on an enabled list only the columns you name can be written.

Each change goes back as a PATCH on the item's fields, with an If-Match header carrying the etag SPSync last saw for that item. If someone has edited the item in SharePoint since then, SharePoint refuses the write with a 412. SPSync records a conflict and does not try again over the top of the newer edit, because SharePoint wins when both sides have changed. The losing value goes into a conflicts table in your database with the time and the editor, where you can query it like any other table and decide what to do with it.

Dry run comes first. You see the exact PATCH bodies before anything is sent, and every write that does go through is logged with the value before and after, who approved it and when. The Entra app needs write access to that one site through Sites.Selected and nothing wider.

Staged write-back with approval, the first slice

The part we intend to ship first is narrower than full two-way sync. Instead of watching the database for any edit, the design has SPSync read a table of proposed changes. An agent or an internal app inserts a row naming the item, the column, the old value and the new value. A person approves or rejects it from the command line or the web console, and only approved rows are sent to SharePoint.

We aimed it at agents and internal apps, where someone wants to see a change before it reaches the list. It is designed for replicas on SQL Server, PostgreSQL and MySQL. Plain text, numbers, currency, dates, yes/no and single choice columns can be written in this slice; lookups, people, managed metadata and files stay read-only. Creates and deletes are left out as well, so the first slice only ever edits items that already exist.

This slice is designed and is not scheduled. We will not guess at a date. Customer requests decide when it moves, so if you need it, the most useful thing you can do is tell us which list it is for and what would write to it.

Who needs write-back and who can skip it

Most people who search for two-way sync need the read side. If your database copy feeds Power BI, a dashboard or an agent that answers questions about the list, nothing on this page changes what you get. SPSync does that today. For PostgreSQL, the SharePoint and PostgreSQL two-way sync use case sets out what works now.

A form-driven app that has to update the list this month is a different case, and you should not wait for us. Layer2 Cloud Connector writes back to SharePoint today. Our comparison with Layer2 sets out where each one fits. Some teams run both, with SPSync keeping the reporting copy and the app writing to SharePoint directly, and the next delta brings the change into the database a few minutes later.

Tell us what you would write back

A short call is the quickest way to tell us. Bring the list, the columns you want to write and who or what proposes the change. Book a call and we will tell you plainly whether the first slice covers it.