Who this is for
Operations, finance and IT leads who want two or more business systems to share information, and who want to scope the work properly before asking anyone to price it. It is useful whether you build the integration internally, use a connector, or hire a provider.
How to use this checklist
Work through it for one business event at a time, such as "an order is accepted" or "an invoice is paid". Trying to integrate "everything" at once is the most common reason these projects stall. Aim to answer each item; "we don't know" is a valid answer, and it tells you where the discovery work is.
1. The business event
- Event name, in business language (for example, "customer accepts a quote").
- Trigger: what exactly signals that the event happened, and in which system?
- Outcome: what should be true in each other system afterwards?
- Volume: roughly how many times a day, week or month?
- Timing: does it need to happen within seconds, or is hourly or daily acceptable?
- Today: who does it by hand now, and how long does it take?
2. The systems and how they can be connected
- Systems involved, with the product name, edition or plan, and who administers each.
- Integration method available for each: a built-in connector, an integration platform, a documented API, or only file import and export.
- API access on your plan. Many vendors reserve API features for higher tiers, and most publish request limits. HubSpot, for example, documents limits that vary by plan.
- Authentication: how will the integration log in (API keys, OAuth, a service account)? Who can create and rotate those credentials?
- Test environments: does each system have a sandbox or test account? If not, how will testing avoid affecting real records?
- Vendor constraints: anything the vendor does not allow, or charges extra for.
3. Records, identifiers and ownership
- Records involved (customers, contacts, items, orders, invoices, payments…).
- Source of truth for each record type, and for any field that exists in more than one system.
- Shared identifier: which ID links the same customer or order across systems? Where is it stored?
- Direction: which records flow one way, and does anything flow back?
- Field mapping: for each field, the source, the destination and any transformation (formats, units, tax codes, currencies).
4. Data quality
- Duplicates: how many duplicate customers or items exist today, roughly?
- Required fields that are often empty (tax numbers, addresses, product codes).
- Inconsistent values (for example, "Tex.", "TX" and "Texas" in the same field).
- Clean-up owner: who will fix data before go-live, and by when?
- Historical data: will past records be synchronized, migrated once, or left behind?
5. Exceptions and failure handling
- Duplicates: what should happen if the same event arrives twice?
- Missing or invalid data: hold the record for review, or reject it?
- Conflicts: which system wins when values disagree?
- Outages: what happens when one system is unavailable? How long may records wait?
- Alerts: who is notified when something fails, how, and what are they expected to do?
- Manual fallback: how does work continue if the integration is switched off?
6. People, approvals and privacy
- Sponsor: who can make decisions and resolve disagreements between teams?
- Business owners for each record type.
- Approvals: does any step need a person to approve it before data moves on?
- Personal information: which personal information moves between systems, and is that consistent with what you told people when you collected it? The FTC treats failing to honor your stated privacy promises as a potential deceptive practice, and state privacy laws such as the Texas Data Privacy and Security Act and California's CCPA/CPRA include data minimization and purpose-limitation duties where they apply.
- Access: who can see the integration's logs, which may contain customer data?
- Ongoing owner: who will look after the integration after launch?
7. Acceptance tests
Agree these before work starts. They define "done".
| # | Test | Expected result |
|---|---|---|
| 1 | A normal event with complete data | Records created or updated correctly in every system |
| 2 | The same event sent twice | Only one record; the duplicate is ignored and logged |
| 3 | A required field is missing | Record held for review; a named person is alerted |
| 4 | Destination system unavailable | Record queued and retried; alert after the agreed number of failures |
| 5 | Values disagree between systems | The source of truth wins, as documented |
| 6 | Credentials expire or are revoked | Integration stops safely and alerts; no data lost |
| 7 | Reconciliation report after a test period | No unexplained differences between systems |
Reading your results
- Mostly answered: you are ready to ask for estimates. Send the completed checklist with your request so every provider prices the same thing.
- Gaps in sections 2 or 3: a short, paid discovery to confirm feasibility and ownership is usually money well spent before committing to a build.
- Gaps in sections 4 or 6: fix the data and agree ownership first. An integration will not resolve organizational disagreements.
If you want help turning the checklist into a scope, send us what you have. A partly completed checklist is a perfectly good starting point.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- API usage guidelines and limits, HubSpot Developers
- Overview of SuiteTalk REST Web Services, Oracle NetSuite Help Center
- Data Import, ERPNext documentation (Frappe)
- Privacy and security guidance for businesses, Federal Trade Commission
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.