Run and monitor a data sync

What this achieves

A sync is one run of a connector: a defined set of records moving in a defined direction. This page covers starting one, reading what it actually did, and stopping one that is doing the wrong thing.

Required role: Administrator.

Before you start

You need at least one connector configured. The trigger form tells you when there are none.

Steps

Go to Integrations → Data Sync.
Select Trigger Sync.
Choose the Connector.
Choose the Direction.
Choose the Entity Type.
Start the sync.
Watch it under Active Syncs, then read it in Sync History.
Open the job to see the record counts and any errors.

Direction

Option	Description
Inbound	Records move from the external system into Humavera.
Outbound	Records move from Humavera to the external system.
Bidirectional	Both.

Be careful with Bidirectional. Two systems that both write the same field need a rule about which one wins, and that rule lives in your field mappings and your process rather than in this dropdown.

Example: HC Corp syncing job titles both ways between Humavera and another system, with no agreement about which is authoritative, produces a field that changes depending on which sync ran last.

Reading a completed job

Option	Description
Total	Records the run considered.
Processed	Records it worked through.
Created	New records written.
Updated	Existing records changed.
Skipped	Records deliberately not acted on.
Failed	Records that errored. Listed individually under the job’s errors.

Read Created and Updated on the first run of any connector, and read them against what you expected. A first inbound sync that reports hundreds of creations where you expected updates has matched nothing and duplicated everything.

Example: an inbound employee sync at HC Corp reporting 34 created rather than 34 updated means the mapping did not match existing records. Those are 34 duplicates, and the second run will make 34 more.

Skipped is worth the same attention. A run reporting everything skipped succeeded and moved nothing.

The history table

Option	Description
Connector	Which connector ran.
Direction	Which way the data moved.
Entity	What kind of record.
Status	How the run ended.
Records	How many were involved.
Started / Duration	When it began and how long it took.
Trigger	Whether it was Scheduled, Manual, or started by a Webhook.

Filter by connector, status, or entity type to answer a specific question. The Trigger column matters when a run you did not expect appears — it tells you whether a person or a schedule started it.

Cancelling a run

Open the job and select Cancel Job. The interface states that the job stops and is marked cancelled, and that this cannot be undone.

Cancelling stops further processing. It does not roll back what has already been written. A run cancelled halfway has half-applied its changes, and putting that right is a separate piece of work.

That is the argument for testing a connector on a manual frequency, against a small entity, before scheduling it.

When a connector has no sync adapter

Some connectors report that no sync adapter is configured for the provider. The connector still holds its configuration and credentials, but data synchronisation is not available for it, and triggering a sync tells you so.

What happens next

Completed runs stay in the history, so a connector’s behaviour over time is readable rather than a matter of memory. Where a run failed records, the job’s error list names them — fix the source data or the mapping and run it again. Once a connector has run cleanly a few times manually, raise its sync frequency.