What Table Sync Does
Table Sync copies a datastore from one ActiveManage instance to another and keeps it in step.
Where to find it
Architect Panel → Integration & Connections:
- Table Sync — the syncs and their position
- Data Sources — the alternative, for non-ActiveManage systems
Architect Panel → Activity:
- Activity Log — the audit trail a sync follows
What it is for
- Reference data maintained centrally and used by several instances — categories, price lists, product data.
- A group whose instances each need the same list of organisations.
- A public-facing instance that needs a read-only copy of something maintained internally.
It follows the audit trail
This is the design point worth understanding. A sync remembers the last audit entry it processed, and next time it picks up from there.
So it is not comparing two tables and working out the difference — it is replaying what happened. Only genuine changes travel, in the order they occurred, and a sync that has been off for a week catches up rather than doing a full comparison.
What that gives you
- Cheap when idle. No changes means no work, regardless of table size.
- Deletions carry across. A comparison-based sync struggles to distinguish a deleted row from one that was never there; an audit entry says plainly that it was deleted.
- Order is preserved, so intermediate states replay as they happened.
What it depends on
The audit trail being complete for that datastore. If auditing were off, the sync would have nothing to follow — so the datastore's audit settings are not merely a compliance matter here, they are what makes the sync work at all.
Worth knowing before somebody disables auditing on a synced table to save space.
One direction
A sync has a source and a destination. It is not two-way replication, and edits made at the destination are not sent back — they will also be overwritten when the source next changes that record.
Treat the destination copy as read-only, and enforce that with permissions rather than by asking people nicely.
Table Sync or a data source?
- Table Sync — both ends are ActiveManage instances. It understands the audit trail and the data model natively.
- Data sources — the other end is something else.
Worked example
A group runs one instance per trading company and maintains its product catalogue centrally. Each subsidiary syncs the catalogue hourly. A price change replays to all four within the hour; a quiet afternoon costs nothing, because there are no audit entries to process.
Recommendations
- Use it between ActiveManage instances, and data sources for anything else.
- Keep auditing on for any synced datastore — the sync depends on it.
- Make the destination read-only by permission.
- Sync reference data, not transactional records.