The Series· No. 53 · Act XIII — The Working Surface

By DocuSeller · Published

Sync
DocuSeller · No. 53

Sync you can watch

Nobody wants to watch a sync.

They want one answer: did it work, and if not, what exactly broke.

Most software replies with a green tick and a shrug.

A nighttime worker accepts one run key, rejects a duplicate trigger, and shuts down after its work One run for the same triggerNight workerWake · runThen shut downSame run keyAcceptedSame run keyDuplicate
Wakes up, does the round, shuts down to nothing. Second card gets waved away.

Ours runs two ways. You press the button, or you leave it alone and it goes overnight — a scheduler wakes a worker that spends the rest of its life switched off, does the round, and shuts back down to nothing. If two triggers land on the same night, the second is spotted and dropped.

A sync that ran twice is not a sync that ran better.

Then the dull part, which is the important part. It reads the whole record set out of the accounting system and holds it against ours:

→ new ones get inserted
→ changed ones get updated
→ ones that vanished get retired, not deleted, because deleted is a decision you cannot take back

Accounting and stored records produce insert, update, and retire decisions, while an unreadable record is set aside and logged Compare records before applying changesAccountingStored recordsInsertNewUpdateChangedRetireAbsentBadrecordLoggedRetired records remain stored; unreadable records are noted
Three verdicts for every record the sync is allowed to judge. The unreadable one gets a pocket.

There is one verdict the sync is not allowed to reach on its own. When a community leaves you — the contract ends, another firm takes it on — you switch it off rather than delete it. Its packages leave the storefront the same minute, so nobody buys documents you no longer hold. Every order it ever took stays exactly where it is. Then the part that matters: tonight's run reads that community, sees the switch, and steps over it. A person turned it off, so the robot does not get to turn it back on at two in the morning.

Four communities at a time, so a large portfolio does not take all night.

A two-thousand-unit sweep should not be hostage to one bad record.
Five illustrative live gauges separately track processed associations, units, owners, board members, and employees Live counts · example18Associations182Units97Owners8Boardmembers12Employees
Five needles, all moving at their own speed. Nothing labelled "please wait".

So the bad one gets noted and stepped around, and the run finishes.

Meanwhile you can watch it happen. Not one bar labelled "syncing" for four minutes. Live counts, per record type: associations, units, owners, board members, employees, each moving at its own speed.

Every run then keeps its receipt. How many succeeded, how many were skipped, how many failed. A summary in plain English. A de-duplicated log naming what failed and why — the record, the reason, not "an error occurred".

Including the status nobody enjoys writing: partially succeeded.

Because that is what happened, and a green tick would be a lie that resurfaces at 8am with a closing waiting on it.

An illustrative five-night customer history identifies one partially succeeded run and names its unreadable owner record Nightly runs · illustrative historyMonTueWedThuFriCompany ACompany B!Company CPartially succeeded · one unreadable owner record
You get to see the bad square before the phone rings.

And across every customer there is a board of last night's runs. You see the bad square before the phone rings.

Next: the room behind every tenant, where all the defaults live.

#Automation · #PropTech · #SaaS