OptiSync — The foundation
One version of the truth, in every system
Bidirectional sync between your CRM, ERP, accounting and finance systems. Field-level mapping without code, duplicates caught before the write, and a run history that tells you exactly what happened.
- Both directions
- Scheduled and event-driven
- No-code mapping
- Full run history
Sales quotes off one customer list. Finance invoices off another. Nobody can say which one is right, so everyone checks both and trusts neither.
How it works
Four steps to a single record
An OptiSync integration goes live in four steps: connect the systems, map the fields, set the matching rules, then run it on a schedule or an event and watch the history. We start read-only, so you see exactly what would be written to your own data before a single record moves.
Connect the systems
CRM, ERP, accounting, whatever else holds the truth. Read-only first, so you can see what would happen before anything moves.
Map the fields
Source field to destination field, with transforms in between. Point and click. No script to maintain, no developer in the loop.
Set the matching rules
Decide what makes two records the same — account number, email, tax number. Duplicates are caught before the write, not cleaned up after.
Run it and watch it
On a schedule, on an event, or both. Every run keeps a record-level history you can search when someone asks what happened.
What it looks like
Read, map, match, write — and keep the receipt
Every OptiSync integration does the same four things: it reads from each connected system, maps the fields, matches the record against your rules, then writes back and keeps a record-level log. The schematic below is one customer integration — the same systems appear on both sides because sync runs both ways.
Field mapping
Source field, transform, destination field
Configured in the interface, versioned like everything else. Example rows from a CRM-to-ERP account sync.
| Source field | Transform | Destination field |
|---|---|---|
| Account.billing_address_postalcode | Trim + uppercase | DR_ACCS.POSTCODE |
| Account.name | Truncate 60 | DR_ACCS.NAME |
| Contact.first + last | Concatenate | Contacts.Name |
| Opportunity.amount | Currency → NZD | Invoices.SubTotal |
| Account.credit_hold_c | Boolean → Y/N | DR_ACCS.ON_HOLD |
Run history
Every run, kept and searchable
Drill from a run into the individual records it touched. When someone asks why an account did not appear in the ERP, you stop guessing.
- 02 Sep 04:001,842 records0 failedCompleted
- 01 Sep 16:00312 records7 held as duplicatesCompleted with warnings
- 01 Sep 04:001,795 records0 failedCompleted
- 31 Aug 16:000 recordsERP endpoint timed outFailed
- 31 Aug 04:001,761 records2 retried, then writtenCompleted with warnings
- 30 Aug 04:001,749 records0 failedCompleted
Illustration of a run history. Timestamps and counts are examples.
Capabilities
What every integration ships with
Every OptiSync integration runs in both directions, on a schedule or an event, transforms fields without code, scores duplicates before writing, keeps a record-level run history, and fails a single record rather than the whole run.
Both directions
Push and pull on the same object. Set which system wins per field, so an ERP price never gets overwritten by a stale CRM value.
Scheduled and event-driven
Nightly batches for the heavy loads, webhooks for the things that cannot wait. Configure each integration separately.
Transforms without code
Split names, normalise country codes, look up a mapping table, concatenate an address. Configured in the interface.
Duplicate detection first
Candidate matches are scored against your rules before the write. Merge, skip or hold for review — your choice, per integration.
Record-level run history
Every run, every record, every failure and every retry, kept and searchable. When finance asks, you have the answer.
Fails safely
A bad payload fails that record, not the run. Failures queue for retry and the rest of the batch carries on.
Straight answers
The questions buyers actually ask
Conflicts, duplicates, awkward legacy APIs and failed runs — answered the way we would answer them on a call.
What if the two systems disagree?
Conflicts are settled in advance, per field: one system is the source of truth for that field and the other yields. Where a genuine conflict cannot be resolved by rule, the record is held and surfaced rather than silently overwritten.
Will this create duplicates in our CRM?
No — matching runs before the write, not after, so a duplicate is caught before the record is created. You set what makes two records the same, and candidates that score below your threshold are held for a human instead of being written.
Our ERP is old and the API is awkward. Does that matter?
An old system with an awkward interface is usually still workable. We have connected plenty whose only interface is a database view, a flat file drop or an ODBC connection. Tell us what it exposes and we will give you an honest read.
What happens when a run fails halfway through?
Records are processed individually, so one bad payload fails that record and nothing else. Failed records queue for retry, the run finishes, and the history shows exactly which records did not make it and why.
How is this different from a generic automation tool?
A generic automation tool moves a record when something happens; OptiSync reconciles two systems that both hold customers, both hold invoices, and both think they are right. That job needs field-level mapping, matching rules and a run history, which is what OptiSync is built around.
Bring us the two lists that disagree.
Thirty minutes, your actual customer data, an honest read on how much of it is duplicated and what it would take to reconcile.
No obligation. No procurement process to start a conversation.