When duplicate data entry becomes an integration problem
How to map where information is re-typed, decide which system owns it, and tell whether you need an integration, a process change or nothing at all.
Business Systems & ERP
Business system integration
When the same customer, order or employee record is keyed into several systems, errors and delays follow, and nobody is sure which copy is right. We connect business applications through supported APIs, middleware and event-driven patterns, design for the day something fails, and hand over documentation your team can operate.
Who this service is for
A good fit if
- Staff re-enter the same information into several systems, such as a CRM, ERP, finance platform and service desk.
- Systems that should agree regularly do not, and nobody can say which record is correct.
- You have point-to-point scripts or connectors that "mostly work" but fail without anyone noticing.
- You are replacing a CRM, ERP or HR system and need data flowing to and from the rest of your application estate.
- You want single sign-on and automated user provisioning across your business applications.
- You need an integration layer that your IT team can monitor, secure and extend.
Another approach may suit you better if
- The problem is really an unclear process. Sometimes a changed procedure removes the need for an integration, and we will say so.
- A system has no API, export or supported integration method, and its vendor will not allow one.
- You only need a one-time move of data between two systems. A scoped data migration is usually simpler.
What this service is
System integration means getting separate applications to share information reliably, so that an event in one system, such as a paid invoice, a new hire or an approved order, updates the others without someone retyping it. In a larger organization that can mean dozens of applications: ERP, CRM, finance, HR and payroll, the IT service desk, e-commerce, identity and a data warehouse.
The connection itself is often the smallest part. The harder questions are which system owns each piece of information, what should happen when records conflict, how duplicates are recognized, and who finds out when something fails. We answer those first. If you are not sure whether you need an integration at all, start with when duplicate data entry becomes an integration problem, then work through the integration readiness checklist.
Integration patterns we use
We pick the simplest pattern that will stay reliable at your volumes, and we often combine several in one program.
- APIs and webhooks. REST, SOAP and GraphQL APIs for reading and writing records, and webhooks so a system can announce a change the moment it happens.
- Integration platforms and middleware. Platforms such as Microsoft Power Automate, Azure Logic Apps, Boomi or MuleSoft give you one place to manage mappings, schedules, credentials and monitoring, instead of scripts scattered across servers.
- Event-driven integration. Message queues and event buses, such as Azure Service Bus, Amazon SQS and EventBridge, or Apache Kafka, decouple systems so that a slow or offline application does not stop the others.
- Scheduled and file-based exchanges. Where a legacy or vendor system only supports file drops or database exports, we build validated, monitored batch jobs rather than manual uploads.
- Identity integration and SSO. We connect business applications to your identity provider, such as Microsoft Entra ID, Okta or Google Workspace, using SAML or OpenID Connect, and automate joiner, mover and leaver provisioning with SCIM where the application supports it.
- API management. When you expose your own APIs to partners or customers, a gateway handles authentication, throttling, versioning and logging.
Demonstration, not a client project
Worked example: web order to CRM to ERP
This example uses invented data. It shows how we document an integration, not work done for a client.
Business event: a customer accepts a quote on a fictional distributor's website.
| Step | System | What happens | Owner of the data |
|---|---|---|---|
| 1 | Website | Customer accepts quote Q-1042 | Website (acceptance only) |
| 2 | CRM | Deal Q-1042 moves to "Won"; contact updated | CRM owns contacts and deals |
| 3 | ERP | Sales order and invoice created for customer ID C-2291 | ERP owns orders, invoices and payments |
| 4 | CRM | Invoice number and status copied back for sales visibility | Read-only copy in CRM |
Identifiers. Each customer carries one shared ID (C-2291) stored in both systems. Matching on email address alone is avoided because people change jobs and share inboxes.
When things fail:
- ERP unavailable: the order message waits in a queue, is retried with increasing delays, and an alert goes to the named owner after the agreed number of failures.
- Customer not found in the ERP: the message is held for review instead of creating a possible duplicate.
- Same acceptance received twice: the quote number is used as an idempotency key, so the second copy is ignored.
Reconciliation: each morning, a report lists won deals from the previous day that have no matching sales order. An empty report is the goal; anything listed gets fixed at its source.
Limits: API rate limits and available features depend on each vendor's plan. For example, HubSpot publishes different API limits for different plans.
Security, privacy and data residency
Integrations move personal and financial information, so they sit inside your privacy obligations under PIPEDA and any provincial law that applies to you, such as Quebec's Law 25. We use encrypted connections, least-privilege service accounts and managed secrets, and we design logs to record what moved without copying sensitive content unnecessarily. Where data residency matters, integration components can run in Canadian cloud regions operated by AWS, Microsoft Azure and Google Cloud. Region choice supports residency, but it does not on its own mean every connected vendor keeps data in Canada, so we check each one with you. This is general information, not legal advice.
Platforms we commonly work with
We work with ERPs, CRMs, finance, HR, e-commerce and identity platforms that provide documented APIs or supported connectors. Typical examples include Prometheus and ERPNext, HubSpot, Salesforce, NetSuite, Microsoft 365 and AWS services. Mentioning a product here does not mean we hold partner status with that vendor, and it does not replace checking what your specific subscription allows. Once systems are connected, many organizations go on to automate the workflows that run across them.
What is included
The exact list is agreed in writing for each project. These are the usual deliverables and the usual boundaries.
Typical deliverables
- An integration inventory and map naming each business event, source system, destination system and the system that owns each field.
- An API and platform feasibility check against vendor documentation, plan limits, authentication options and data residency needs.
- A pattern decision for each flow, such as a native connector, an integration platform, event-driven messaging or a small custom service.
- Field mappings with transformation rules, shared identifiers and duplicate handling.
- The integrations themselves, built and deployed in your environment.
- Error handling with retries, an exception queue for failed messages, and alerts to a named owner.
- Reconciliation reports or checks that show when systems disagree.
- Single sign-on and user provisioning with your identity provider, where in scope.
- Test evidence, architecture documentation and an operations runbook.
Not included unless agreed separately
- Vendor subscriptions, integration platform licences and API tier upgrades, which you buy directly from the vendor, with our advice.
- Cleaning up years of historical data, unless scoped separately.
- Ongoing monitoring and support after handover, unless covered by a managed-service agreement.
- Accounting, tax or legal advice about how records should be treated.
- Changes to third-party products that their vendors do not support.
What we will need from you
Most delays in this kind of work come from access and decisions, not from the technical build. Knowing these early keeps the project predictable.
- Admin or API access to each system, ideally in a sandbox or test environment.
- A business owner who can decide which system is correct when two disagree.
- Sample records, with personal information removed or replaced where possible.
- Confirmation of your subscription plans and licence tiers, since many API features depend on them.
- Your security and change-management requirements, including how credentials and network access are approved.
Delivery
How the work is delivered
Larger programs are delivered one business event at a time, so each flow is proven before the next is added.
Discover and map
Inventory the systems, identify the business events that cross them, and trace one priority event in detail, including who enters what, where it goes and where it breaks today.
Output: Integration map and source-of-truth decisions.
Design the architecture
Confirm APIs, limits, authentication and hosting on your actual plans, then choose the pattern for each flow and how it will be monitored.
Output: Integration design and feasibility note.
Build and test
Build against sandboxes where possible. Test normal records, duplicates, missing fields, expired credentials, rate limits and each system being unavailable.
Output: Working integrations and test evidence.
Go live and reconcile
Switch on in a controlled way, compare records between systems for an agreed period, and fix mismatches at their source.
Output: Reconciliation results and go-live sign-off.
Hand over or manage
Walk your team through the runbook, credential handling and alert routing, or move the integrations into ongoing support if you choose.
Output: Runbook, handover session and an agreed support arrangement.
Testing and handover
- Every failure path is tested, including bad data, duplicates, expired credentials, throttling and a system being offline.
- Failed messages are kept and visible, with a documented way to replay them.
- Credentials are stored in a secrets store or the platforms' secure settings, never in spreadsheets or code.
- Integration accounts use least-privilege permissions and belong to the organization, not an individual.
- A reconciliation check shows whether systems still agree after go-live.
- The runbook explains what each alert means and what to do about it.
What affects the cost
We do not publish package prices. Each estimate is based on an agreed scope, in Canadian dollars, with taxes shown separately. These are the things that move the number most:
- The number of systems, business events and data volumes involved.
- Whether systems have well-documented APIs or need file exchanges, workarounds or legacy adapters.
- Data quality, including duplicates and inconsistent identifiers.
- How quickly data must move (scheduled batches are simpler than near-real-time events).
- Security, audit and data residency requirements.
- The monitoring, reporting and support you need after go-live.
Questions buyers usually ask
Should we use an integration platform, middleware or custom code?
If a supported connector or integration platform handles your case reliably, it is usually the better choice because others can maintain it. Custom services make sense for logic specific to you, high volumes, or where platform licensing outweighs the benefit. We compare the options in the design stage using your actual plans and volumes.
What happens when one of the systems is down?
The integration should detect the failure, keep the message, retry with increasing delays and alert someone if it keeps failing. Designing for failure is a large part of the work, and we test it before go-live.
Which system should be the source of truth?
Usually one system per type of information: for example, the CRM for contacts, the ERP for orders and invoices, and the HR system for employees. We help you decide field by field, and the decisions are written down.
Can you integrate HubSpot, Salesforce, NetSuite or ERPNext?
Yes. These products publish APIs, and we confirm what your specific plan allows before committing to an approach. We do not hold partner status with these vendors, and licences are bought from the vendor.
Where do the integrations run, and where is our data stored?
They can run in your cloud tenant, on your own infrastructure or on a managed integration platform. Where data residency matters, integration components can be hosted in Canadian cloud regions, but some SaaS vendors process data elsewhere, so we review each vendor's terms with you.
Who maintains the integrations afterwards?
Your team, another provider, or Promatics under a managed-service agreement. The runbook is written so that any competent team can take over.
Related
Integration readiness and scoping checklist
Everything an integration project needs settled before it can be priced, as a checklist you can fill in with your team.
Workflow and business process automation
Automate repetitive, rule-based workflows with human approval where it matters, a clear audit trail and a tested manual fallback.
Typing the same data twice?
Describe the systems involved and where information gets re-entered or goes missing. We will reply to arrange a conversation about whether integration is the right fix.