Table Sync

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.

Setting Up a Sync

A sync names the far instance, the table at each end, and how often to run.

Where to find it

Architect Panel → Integration & Connections:

• Table Sync — the syncs themselves

Architect Panel → Data:

• Datastores — the tables at both ends

Architect Panel → Security:

• Permissions — making the destination read-only

What it holds

• The address of the other instance and a key to reach it.
• The source table and the destination table.
• A frequency.

The two tables must match

Same fields, same names, same types. A sync copies values into fields — it is not a mapping layer, and a field missing at the destination is a value with nowhere to go.

The reliable way to achieve this is to build the destination from the source's definition rather than by hand. Two people creating "the same" datastore independently will differ in something.

Keep them in step afterwards

This is the ongoing discipline. Adding a field at the source and not at the destination breaks the sync, and the break happens at the next change to that table rather than at the moment you made the schema change — so the cause and the symptom are separated by hours.

Make "change both ends" part of how you edit a synced datastore.

Frequency

Match it to how quickly the copy must be current, not to how often it could run. Reference data changing a few times a week does not need a five-minute sync — that is load with no benefit.

Hourly suits most reference data. Reach for minutes only when somebody is genuinely waiting on the far side.

The first run

Understand what happens with existing data before you enable a sync onto a table that already has rows. Two populated tables with independent histories are the awkward case; an empty destination is much simpler.

Where you can, start from an empty destination and let the sync populate it.

The key is a credential

It grants a remote instance the ability to write into your datastore. Give it the same care as any other credential — not shared with other integrations, and rotated on a schedule you keep.

Make the destination read-only immediately

Before anybody sees it. A destination copy that people can edit will be edited, and their changes will vanish at the next source change — which reads as data loss and is very hard to explain after the fact.

Test with a real change

Change one record at the source and watch it arrive. Then delete one and confirm the deletion carries across, because that is the case most likely to be misconfigured and the one people notice last.

Worked example

A subsidiary's catalogue datastore is created from the parent's definition, left empty, and synced hourly. The first run populates 1,400 products. A test price change arrives within the hour and a test deletion removes the row. The destination is then granted read-only to every group.

Recommendations

• Build the destination from the source definition.
• Change both ends together, always.
• Start from an empty destination where you can.
• Test a deletion, not just an edit.

When a Sync Falls Behind

A sync records how far it has got. Everything about diagnosing one comes back to that marker.

Where to find it

Architect Panel → Integration & Connections:

• Table Sync — the syncs and their recorded position

Architect Panel → Activity:

• Activity Log — the entries being replayed
• Error Log — failures during a run

The position marker

Each sync remembers the last audit entry it processed. A run picks up from there and works forward.

That single number explains most behaviour: a sync that is up to date has a marker near the end of the audit trail, and one that has fallen behind has an older one and a backlog to work through.

Falling behind is usually catching up

A sync that has been off — a scheduling problem, an unreachable instance, a maintenance window — is behind rather than broken. Left running, it works forward through the backlog and arrives.

Check the marker is moving before treating it as a fault. A marker that advances is a sync that is fine and merely slow.

A stuck marker is the real problem

If it is not moving, something is refusing. Common causes, roughly in order:

• A field added at one end and not the other.
• The far instance unreachable, or its key rotated.
• A value the destination rejects — a validation rule that differs between the two.
• A referenced record that does not exist at the destination.

It stops rather than skipping

When an entry cannot be applied, the sync does not step over it and carry on. That is deliberate, and it is the right choice: skipping would leave the two ends silently divergent in a way nobody would notice until somebody compared them by hand.

A stopped sync is a visible problem. A skipping sync is an invisible one, and invisible divergence is much worse.

Fix the cause, then let it resume

Do not move the marker past a failing entry to get things running again. It will work — and it discards a change that everybody will assume was applied. If the entry genuinely cannot be applied, understand what it was before deciding to skip it, and record that you did.

The audit trail must still hold it

A sync behind by longer than your audit retention has a gap it cannot replay. If retention on a synced datastore is short and a sync has been off for a long time, re-establishing from a fresh copy may be the only honest recovery.

That is an argument for keeping audit retention comfortably longer than any outage you would tolerate.

Watch the markers routinely

A sync failing is quiet — the destination simply stops changing, which looks identical to nothing having happened at the source. Check the positions periodically rather than waiting for somebody to notice stale data.

Worked example

A nightly check shows one sync's marker unchanged for two days. The error log names a field the destination does not have — a column added at the source on Monday. The field is added at the destination, the sync resumes on its own, and it clears two days of backlog in a few minutes.

Recommendations

• Check the marker is moving before diagnosing anything.
• Never skip past a failing entry to get it running.
• Keep audit retention longer than any outage you would accept.
• Monitor sync positions — failure is silent at the destination.