An integration is a change to how business records move, who can access them, and how the team resolves conflicts. Treat it as an operating and data-governance decision.
Scope note: This is a general evaluation checklist. It does not claim that any particular product, provider, service, API, connector, sync method, security control, or outcome is available.
Start with the record that matters
For each proposed connection, name the source record, destination record, business owner, and the decision the connection is meant to support.
| Area | Questions to verify |
|---|---|
| Customer records | Which fields are necessary, and which are prohibited from sharing? |
| Job and appointment records | Which system is the source of truth for each state? |
| Financial records | How are invoice, payment, refund, and reconciliation states distinguished? |
| Communication records | What consent and retention rules apply? |
| Staff and access records | Which roles may view, edit, export, or delete information? |
Do not assume that two systems use the same definitions or that a matching field means the records are equivalent.
Define a source of truth
Write down which system owns each record and what happens when information conflicts. A connection should not silently overwrite an authorized record without a documented, reviewable rule.
Keep a clear path for:
- detecting incomplete or conflicting information;
- pausing a transfer that cannot be explained;
- correcting a record with an authorized owner;
- exporting only the data the business is allowed to use;
- retiring a connection without losing the required business record.
Verify privacy, access, and terms
Before using live records, review the current official documentation, contract, permissions, retention controls, and support process for the exact provider and plan under consideration.
Do not post real customer, employee, account, payment, location, credential, token, log, or screenshot data in a public guide. Use synthetic examples that contain no production information.
Test a small, reversible case
Begin with a limited, non-sensitive workflow. Define the expected record before the test, run the test with cleared or synthetic data, and inspect the final records in both systems.
The test should answer:
- Was the authorized data transferred?
- Did the expected owner retain the right access?
- Can the result be explained from the business record?
- Is there a documented way to correct or reverse an error?
If the answer is unknown, keep the integration limited until it is verified.
Keep capability claims current
Providers can change functionality, availability, pricing, and data practices. Verify those claims directly with the relevant official source at the time of the decision.
Discussion
Which record would your team require to have a single, clearly documented source of truth before connecting systems?