Skip to content

Replication jobs

Two jobs on the sending server perform the replication. Both have dedicated entries under Administration › Replication (Replicate System Configuration and Replicate Recordings) and also appear in the jobs console, where runs, processing records, and logs are monitored like any other job.

Both jobs share the connection settings:

  • Target URL — the receiving server's address (HTTPS), with an option to verify the SSL certificate.
  • Replication token — the token ID and secret created on the receiving server (see Configuration).

Replicate System Configuration

Pushes configuration records (tenants, users, roles, AI tasks, and the other tables listed in Replication overview) to the target server. The job's Data source setting decides how it finds work:

  • Incremental using replication slot — consume the changes captured by a replication slot. This is the steady-state mode: each run sends only what changed since the previous run.
  • Full modes — rescan and send all records. Useful for the initial synchronization or to repair a drifted target.

Run results show Replicated records and Conflicts (records the receiving side refused to apply, for example because its copy is newer under the If newer update strategy).

Replicate Recordings

Pushes conversations to the target server. Call metadata is always sent; the job additionally replicates audio files, evaluation reports, and transcripts according to its Replicate data selection (the receiving token must allow the same types). Audio files are uploaded in resumable chunks (5 MB by default), so an interrupted transfer of a large file continues instead of restarting.

Operational behavior worth knowing:

  • Conversations still in progress are skipped with a warning (call is still active) and picked up on a later run once they complete.
  • Already-replicated conversations are skipped, so re-running the job is safe.
  • Run results separate Replicated metadata, Replicated files, file-access warnings, and Conflicts.

Like other conversation-processing jobs, the job's Filtering criteria limit which conversations are replicated (for example, one tenant only), and its schedule can be continuous or periodic — see the jobs console.

Post-processing chains

Replication plugs into the processing-queue pipeline on both sides:

  • On the sending server, the Replicate Recordings job publishes a Call - Replication sent event for each replicated conversation, so a queue can trigger follow-up processing after successful handoff.
  • On the receiving server, each arriving conversation raises a Call - Replication received event, and the replication token's Publish received records to queue(s) option feeds received conversations into queues directly. Attach the transcription job to such a queue and the receiving server transcribes and analyzes replicated conversations with its own Conversation Analytics pipeline.

Verifying replication

  • Watch the two jobs' Latest run / All runs tabs for errors and conflicts.
  • On the sending server, confirm the replication slot's queue length returns to near zero after each system-configuration run.
  • On the receiving server, open the replication token to review the received-data report and any per-record errors recorded for that token.
  • Replication send/receive activity is also recorded in the audit trail.