CRM Development & Integrations

Integrations that prove they are working.

CRM integration and custom development for Salesforce, HubSpot and Odoo. ERP, billing, e-commerce, telephony and data platforms connected with monitoring, daily reconciliation and a named owner built in — so you can always tell the data arrived.

Talk about an integration See the integration map

Two-way sync, retry policy, dead-letter queue and an owner who gets paged. Written into the design, not discovered in production.

7
System categories we connect to a CRM
3
CRM platforms we build on
90+
Engineers in the Agmis group
EU
Based in Kaunas, delivering across Europe

Where integrations break

Four ways an integration fails, and only one of them is loud

Most integration projects are judged on whether the data arrives. They should be judged on what happens on the day it does not.

SILENT

The sync stops and nobody notices

A token expires, a field is renamed, an API changes a limit. Records stop arriving. Nothing errors on screen, so the first signal is a report that looks slightly wrong three weeks later.

LOUD

It fails and floods someone with alerts

The opposite failure, and just as expensive. Retries hammer a dead endpoint, the channel fills with noise, and within a week people mute the alerts that were supposed to protect them.

STRUCTURAL

Point-to-point sprawl

Six systems, eleven direct connections, nobody able to say which one owns a changed phone number. Every new tool adds two more links, and the whole thing becomes unauditable.

OWNERSHIP

Everyone assumes someone else owns it

The integration was built by a partner who left, documented in a spreadsheet, and monitored by nobody. When it breaks, the first 48 hours are spent working out who built it.

A failed sync should be a queued record with an error attached, not missing data. That is a design decision, not an operational hope: idempotent writes, a retry policy with backoff, a dead-letter queue you can inspect, a reconciliation job that compares counts daily, and a named person who gets paged.

What we build

Four kinds of work, and what each one is for

Configuration first, code only where configuration genuinely runs out. Most integrations should be configuration, because configuration is what your team can still change in a year.

01 · CONNECT

Integrations between systems

ERP, billing, e-commerce, telephony, support and data platforms connected to the CRM. Direction decided per object rather than per system, so you are never syncing a field in both directions and wondering which one wins.

Result: one customer record that finance, sales and support all accept.

02 · EXTEND

Custom development on the platform

Custom objects, custom-coded actions, Apex and Lightning components on Salesforce, custom modules on Odoo, custom-coded workflow steps on HubSpot. Built only where a standard object genuinely cannot carry the shape of the business.

Result: the system fits the process instead of the process bending to a picklist.

03 · AUTOMATE

Automation and data movement

Approvals, routing, enrichment, deduplication at the point of entry, scheduled reconciliation, and the data cleaning that has to happen before any of it is trustworthy. Automation that is documented is automation that can be changed.

Result: fewer manual steps, and a record of what ran and when.

04 · MAINTAIN

Ownership after the build

Monitoring, alerting, API version upgrades, retry tuning and a quarterly look at whether each connection still earns its place. An integration nobody maintains degrades on the platform's release schedule, not yours.

Result: it is still working in two years, and someone knows why.

The artefact

The integration map is the deliverable

Before anything is built, you get a document that names every system, every direction, every field that moves and every failure mode. It is the thing you review, the thing you own, and the thing the next engineer will read.

System
Your CRM
What moves
ERP / financeNetSuite, Dynamics, Odoo
Two-way
Orders out, invoices and customer master back. Direction decided per object.
BillingStripe, Chargebee, Recurly
One-way
Subscription state, MRR, churn and dunning, so the account record shows revenue rather than intent.
E-commerceShopify, WooCommerce, Magento
One-way
Customers, orders and abandoned checkouts. Deduplicated against existing accounts on entry.
TelephonyTwilio, Aircall, CloudTalk
Two-way
Call logs and recordings attached to the record, and click-to-dial back out from the CRM.
Support deskZendesk, Intercom, Freshdesk
Two-way
Cases, SLA state and conversation history, so service and sales stop describing the same customer differently.
Data warehouseSnowflake, BigQuery, Power BI
One-way
Full extracts on a schedule, read-only, so BI stops depending on someone exporting a spreadsheet.
Internal toolsLegacy databases, internal APIs
Two-way
Whatever the business actually runs on. Usually the most important connection and the least documented.

Every row carries the same four facts in the delivered map: direction, frequency, failure behaviour and owner. A connection without those four is a diagram, not a design.

The honest question

Connector, middleware or custom code

Three options, three price points, and the cheapest one is right more often than vendors of the other two would like. We will tell you which applies before quoting.

Chosen per connection, not per project. A typical CRM has all three kinds in it.
ApproachRight whenWatch out for
Native connectorBoth systems are mainstream, the fields map one to one, and volume is modest.Field changes on either side break it quietly. Test upgrades before they land.
Middleware or iPaaSSeveral systems, several directions, and someone needs to see the errors without reading code.Per-task pricing grows faster than usage. Model volume before you commit.
Custom codeThe data model genuinely does not fit, volumes are high, or there is no connector for either side.Whoever builds it has to be reachable in two years. Demand source access and documentation.

There is no licence markup in our advice, and the recommendation is not funded by a partner programme.

How it runs

From map to monitored, in five steps

Integration work is mostly design. The code is the short part, which is why the map comes first and the build comes third.

01

Inventory

Every system, who owns it, what it holds, and which direction data ought to move. Including the spreadsheet someone maintains because the old integration never worked.

02

Map

Objects and fields per connection, direction, frequency, transformation rules, conflict resolution and failure behaviour. Reviewed and owned by you before build.

03

Build

Configuration where it suffices, middleware where several systems are involved, code where the model genuinely does not fit. Built against a sandbox copy of both ends.

04

Test and rehearse

Failure injected on purpose: expired tokens, malformed records, endpoint timeouts. If the retry and dead-letter behaviour has never been exercised, it is not known to work.

05

Monitor

Alerting that reaches a named person, a daily reconciliation count, an error queue someone can read, and an owner recorded in the map. Then hand over or maintain.

Proof

What an integration project actually changes

Three engagements where the useful work was connecting the system, not replacing it.

Nonprofit

Bank integration for a national Red Cross society

Limited integration with local banking platforms meant only around 60% of recurring donations processed. The fix was automated reconciliation against the bank, on the platform already in place.

Read case study
Logistics

Customer service and sales management at parcel-delivery scale

Enquiry volumes outgrew the process. Intake moved into one queue so every channel landed on a single record, with SLAs visible to the people who had to meet them.

Read case study
Fintech

Client onboarding transformation for a licensed EMI

KYC onboarding moved out of email and spreadsheets into a single flow, where the compliance state is a field rather than a folder of attachments.

Read case study

Tell us which systems have to agree with each other

We will tell you which connections are worth building and which one is going to be the difficult one.

Talk about an integration

Across the platforms

Development and integration on each platform

Same discipline on all three: configuration where it suffices, code where it does not, and failure handling written in either way.

Apex, APIs, Platform Events

Salesforce development

Apex, Lightning Web Components, Platform Events, Flow and the standard APIs. Middleware where several systems are involved, and a dead-letter queue where anything can fail.

Custom code and workflow actions

HubSpot development

Operations Hub custom code, custom-coded workflow actions and the CRM APIs. The right answer when sync volume outgrows a native connector or the mapping is not one to one.

Python modules and the ORM

Odoo development

Python modules written against the ORM, scheduled actions and the external API, so the connection lives inside Odoo rather than in a script beside it that nobody owns.

FAQ

CRM development and integrations, answered

What is CRM integration?
CRM integration is the work of connecting the customer system to the other systems a business runs on, so that one record is authoritative instead of several. In practice that means ERP and finance, billing and subscriptions, e-commerce, telephony, support desks, data warehouses and internal tools. It covers the direction data moves, how often, what happens on a conflict, and what happens on a failure. The last of those is the one that separates an integration that survives two years from one that quietly stopped working last quarter.
What happens when an integration fails?
It depends on the design, which is exactly why we publish it. The pattern we build is: idempotent writes so a retry cannot duplicate, exponential backoff so a dead endpoint is not hammered, a dead-letter queue holding records that failed with the error attached, a daily reconciliation job comparing counts on both sides, and an alert routed to a named person rather than a shared inbox. The failure is then a queue you can inspect and replay, not a gap in the data nobody finds for a month.
Do you build integrations on all three platforms?
Yes. On Salesforce that means Apex, Lightning components, Platform Events, Flow and the standard APIs. On HubSpot, Operations Hub custom code, custom-coded workflow actions and the CRM APIs. On Odoo, Python modules, the ORM, scheduled actions and the external API. Our engineering depth sits in the Agmis group, which is 90+ engineers, so custom work is not outsourced to a subcontractor you never meet.
Who owns the code you write?
You do, along with the source, the repository access and the documentation. If the work is delivered as a managed package or an Odoo module, you get the module. We do not withhold source as leverage, and the integration map records where everything lives so a future engineer does not have to reverse-engineer it.
Do you use Zapier or Make?
Sometimes, and we will say when it is the right answer: low volume, two mainstream systems, simple field mapping, no compliance constraint on where the data passes through. We will also say when it is the wrong answer, which is usually when volume is high, when the data is personal or regulated, when errors need to be replayable, or when per-task pricing will exceed a built connection within a year.
Can you fix an integration someone else built?
Yes, and that is a common starting point. We begin with the map rather than the code: what connects to what, in which direction, what is supposed to happen on failure, and who owns it. That document usually explains the problem before anyone opens an editor. Where there is no documentation at all, the inventory phase takes longer and we say so before quoting.
How long does an integration project take?
A single two-way connection between mainstream systems is typically two to four weeks including testing, on top of any implementation work around it. A project with several systems, a middleware layer and a warehouse feed is closer to eight to twelve. The variable is the number of connections and the state of the source data, not the platform. The mapping phase runs first and gives you a real estimate before the build is priced.

Before you connect anything

Tell us which systems have to agree with each other

We will tell you which connections are worth building, which should be configuration, and which one is going to be the difficult one. That answer costs nothing and it is usually the shortest path to a scoped project.

Talk about an integration Which CRM fits you?