One record, fed by every system you already pay for
Integration is not a logo on a website. It is deciding which system owns which field, what happens when both of them change it, and what the CRM does at two in the morning when the other end stops answering.
Field-level mapping · Conflict rules agreed upfront · Retry and alert on failure
“Integrated” means three different things
When a vendor says they integrate with Tally, it is worth asking which of these they mean. The gap between the first and the third is most of the work.
Listed
The logo appears on a page.
In practice this is an export button. Somebody downloads a file from one system and uploads it to the other, usually on a Friday.
- CSV export and import
- Manual, on a schedule someone remembers
- No field mapping
Read
The CRM pulls from the other system.
Genuinely useful and often enough. Data moves one way, so there is nothing to reconcile — but the other system stays the source of truth.
- Scheduled or webhook pull
- One direction only
- Read-only in the CRM
Reconciled
Both systems write, and disagreements have rules.
Every field has a named owner, conflicts resolve by an agreed rule rather than by whoever saved last, and anything ambiguous is held for review instead of guessed.
- Two-way with field ownership
- Conflict rules written down
- Differences reported, not silently merged
This is what we build unless you tell us otherwise.
Every field gets an owner before anything syncs
This is a real shape of a Tally, Razorpay and Calendar mapping. Boring to read, and the reason the numbers still agree a year later.
Agreed and signed off before a single connector is written. It is the least interesting document in the project and the one that prevents the arguments.
What happens when the other side stops answering
Integrations do not fail loudly. They fail quietly, at night, and you find out from a customer three weeks later. These are the states we build for.
The other system is down or timing out
Writes queue locally and retry with backoff. Nothing is dropped, and the queue depth is visible in the admin screen.
A token expired or credentials were rotated
Sync pauses and your admin is alerted the same hour. It does not keep retrying quietly against a dead key.
Both systems changed the same field since the last sync
The record is held, both versions are kept, and it appears in a review queue rather than one silently overwriting the other.
They changed a field or a response shape on their side
Sync halts rather than writing malformed data. We would rather you have yesterday's numbers than corrupted ones.
Their API caps how much we can send per minute
Throttles automatically and resumes, prioritising anything customer-facing ahead of background reconciliation.
Repeated failures over a defined window
The integration stops itself and raises a ticket with us, so a broken connector cannot spend a week writing bad data.
What to ask before believing a logo
Something specific to your setup? Ask an engineer
Bring us the two systems that never agree
Tell us which numbers your team reconciles by hand each month. That reconciliation is usually the integration worth building first.
- Field ownership agreed before we write code
- Conflict rules in writing, not in someone's head
- Queue and retry when the other side is down
- Connector maintenance covered by support