Question 1

Why land Plain data in SQL Server?

Accepted Answer

Typically because the reporting layer is already there. Teams with established stored procedures, scheduled reports or a business intelligence tool pointed at SQL Server would rather add support conversations to that environment than stand up a separate stack for one source. Once threads and companies are in the same database as revenue and account tables, the joins people actually want become ordinary queries.

Question 2

How does Plain's nested data fit a relational schema?

Accepted Answer

Better than you might expect, because much of it is normalized before it arrives. Timeline activity is its own table with one sparse row per event rather than a nested blob on the thread, and messages, notes, attachments, components, links and discussions are separate tables too. What genuinely nests, such as label arrays and thread custom fields, is stored in JSON compatible columns, which the built-in JSON functions can shred when you need it relationally.

Question 3

What does an incremental run actually move?

Accepted Answer

Only threads, customers, companies, tenants and several reports read incrementally; the rest are read in full each time. Incremental reads use Plain's updated timestamp with the checkpoint set ten minutes earlier than the run start, so records changing near a boundary are captured rather than skipped. Child records are then fetched for the threads that moved. The overlap means duplicates are possible, so define a primary key and let the destination merge.

Question 4

Will deleted Plain threads disappear from SQL Server?

Accepted Answer

No. Plain does not publish deletion markers for threads, so a deleted conversation stops appearing in reads while the existing row remains in the table. Companies behave differently and do carry deletion flags, which come through so you can exclude them in queries. Where a stale thread would distort a report, the dependable fix is a scheduled full refresh of that table rather than expecting incremental ETL to reconcile it.

Connect Plain with Microsoft SQL Server

Connect Plain and Microsoft SQL Server with Polytomic

Normalized into relational tables

Nested values kept as JSON

Support metrics arrive ready made

Trusted by businesses worldwide

Step-by-step integration guide

Connect Plain in Polytomic

Connect Microsoft SQL Server in Polytomic

Create a sync between Plain and Microsoft SQL Server

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect Plain with Microsoft SQL Server?