# Integration readiness checklist

Kode Kinetics — original planning workbook. Version 2026-09-28.

Free to download and complete; no account or email required. This workbook supports scoping, not a certification or a guarantee of successful delivery.

## How to use

Choose one business flow. Work with its business owner, both system owners, and an engineer. For each prompt record verified, unknown, blocked, or not applicable, a dated evidence reference, an owner, and the next action. Explain not-applicable decisions. Never include credentials or personal customer records.

- Flow and business outcome:
- Source and destination:
- Business owner / system owners:
- Prepared by / date:
- Scope exclusions:

## Define one business transaction

Make the boundary small enough that both business and engineering owners can describe a correct outcome.

- [ ] Name the trigger, source, destination, business owner, and outcome. Separate order creation, shipment, invoicing, refunds, and historical migration into explicit flows.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Record normal and peak transaction volume, acceptable delay, operating hours, and the effect of a missed or duplicated transaction.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] List exclusions and manual approvals. Identify who resolves exceptions and who accepts the completed workflow.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A one-page flow with entry/exit conditions, peak-volume evidence, exclusions, and a named business approver.

## Identify systems and access dependencies

A product name alone does not establish that the required interface is available in your environment.

- [ ] Record exact product, version, deployment model, tenant or company boundary, extensions, vendor contact, and environment owner for each system.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Locate the documented endpoint or supported import/export mechanism for each required operation. Record API version, licensing dependencies, limits, and deprecation notices.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Confirm a representative sandbox, permitted test records, and an access approver. Record required permissions and credential rotation ownership without putting secrets in this workbook.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: An environment inventory, endpoint references, and a sandbox access plan with owners and unresolved dependencies.

## Agree record ownership and field mapping

Resolve meaning and ownership before designing synchronization.

- [ ] Name the system of record for customers, products, orders, invoices, and status changes. Define which side may create or update each field.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Map stable source and destination identifiers, required fields, allowed values, units, decimal precision, time zones, and currency codes. Assign business rule decisions to the relevant owner.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Collect anonymized examples for a normal record, missing data, a corrected record, and a cancellation. Define what happens when two systems disagree or a reference record is absent.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A field-mapping sheet with source, destination, transformation, validation, owner, and anonymized sample for every required field.

## Plan delivery, duplicates, and ordering

A network response does not always tell you whether a business operation completed.

- [ ] Choose polling, events, or a batch schedule based on available interfaces and required delay. Document checkpoints and how missed records are found.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Define a stable business-operation identifier and how repeat deliveries are detected. Verify actual destination behavior when the same operation is submitted twice.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Describe timeout-after-acceptance, out-of-order updates, and concurrent edits. Agree how to check destination state before retrying an operation whose outcome is unknown.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A delivery sequence and duplicate/reordering test cases with observable expected outcomes.

## Make failures recoverable

Design the recovery path as carefully as the successful path.

- [ ] Separate transient failures from invalid business data or denied access. Define bounded retry delays, attempt limits, and handling of provider rate-limit responses.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Specify where failed records wait, what context an operator sees, who can correct and replay them, and how replays avoid repeated side effects.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Define reconciliation: compare source and destination counts, identifiers, statuses, and agreed totals over a fixed window. Give unresolved differences an owner and escalation path.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A failure matrix covering timeout, outage, rate limit, duplicate, invalid reference, and partial completion, plus a reconciliation procedure.

## Bound data use and operational visibility

Collect enough evidence to diagnose the workflow without spreading sensitive records into every tool.

- [ ] List data fields crossing each boundary, their purpose, approved destinations, retention expectations, and the person authorized to decide handling requirements.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Define which identifiers and error codes belong in logs, how payloads are redacted, who can inspect them, and how test data is separated from production.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Choose alerts tied to business impact: aged unprocessed records, repeated failures, and reconciliation differences. Assign an operator and coverage expectations.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A data-flow inventory, redacted diagnostic example, alert definitions, and named operational owners.

## Specify acceptance evidence

Agree what must be demonstrated before anyone relies on the integration.

- [ ] Write observable acceptance criteria for the normal transaction and each failure case. Include the expected destination record and a way to reconcile it to the source.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Test peak volume, recovery after an outage, duplicate delivery, expired access, and corrections using authorized representative data.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Record which results were observed in the sandbox, which depend on mocks, and which remain untested. Have the business owner review exception handling as well as the happy path.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: An acceptance matrix linking each requirement to test data, expected outcome, observed evidence, and approver.

## Prepare cutover and ownership

The integration needs a sustainable operating model after implementation.

- [ ] Separate initial backfill from ongoing synchronization. Set a cutover checkpoint and decide how in-flight changes are captured.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Define rollback triggers and how already-created destination records will be reconciled. Reverting code alone may not reverse business transactions.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

- [ ] Assign deployment, monitoring, incident response, vendor-change review, and runbook maintenance. Include expected hosting, licensing, support, and exception-handling effort in planning.
  - Status:
  - Evidence reference and date:
  - Owner:
  - Unknown / next action:

Evidence to collect: A cutover and recovery runbook, handover owners, operating-cost assumptions, and a dated go/no-go decision.

## Field-mapping worksheet

| Source field | Destination field | System of record | Transformation / validation | Anonymized example | Decision owner |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Failure and acceptance worksheet

| Case | Expected business outcome | Recovery / replay rule | Observed evidence | Owner |
| --- | --- | --- | --- | --- |
| Normal transaction | | | | |
| Duplicate delivery | | | | |
| Timeout after acceptance | | | | |
| Invalid customer or item | | | | |
| Rate limit / outage | | | | |
| Partial completion | | | | |
| Out-of-order update | | | | |

## Hypothetical order-to-invoice example

This is not a client result or a vendor API contract. The storefront owns approval of order WEB-1042; the ERP owns customer accounts, item identifiers, and invoices. Preserve WEB-1042 as an external reference and record the ERP order ID. Map customer and product IDs; route unknown references for review. Carry currency explicitly and obtain approved pricing and rounding rules from the business owner.

If order creation times out after acceptance, check destination state through the external reference or a supported idempotency mechanism before retrying. If neither capability is established, run a bounded sandbox experiment before estimating this path. A duplicate-delivery test should produce one intended order; a missing-customer test should yield an actionable exception without an unintended invoice. Reconcile approved source orders to destination references and pending exceptions.

## Decision record

Choose a decision based on evidence, not a percentage score.

- [ ] Ready for scoped discovery: flow, owners, interfaces, and samples available; remaining assumptions listed. This is not deployment approval.
- [ ] Blocked by a dependency: name the missing access, license, decision, or operation and the person who can resolve it.
- [ ] Needs a bounded experiment: specify the uncertain behavior, permitted sandbox/data, expected observation, time limit, and stop condition.

Decision / date:
Open dependencies and owners:
Experiment and stop condition:
Evidence needed to revisit decision:
Next review date:

## Methodology and references

This original workbook follows a transaction through mapping, delivery, failure recovery, acceptance, and operations. Use inspectable evidence and extend the prompts for the actual systems. The references below inform retry and event-delivery questions; provider behavior is not universal. Links checked 2026-09-28.

- [Microsoft Azure Architecture Center: Retry pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/retry) — Explains transient-failure retries, bounded attempts, and why repeated side effects matter. Adapt the policy to the actual operation.
- [Stripe: Receive events in your webhook endpoint](https://docs.stripe.com/webhooks) — A concrete provider example for duplicate events, event ordering, and signature verification. Check each provider’s own delivery contract; these behaviors are not universal.

## Next steps

- [Read the online checklist](https://www.kodekinetics.com/resources/integration-readiness-checklist/)
- [API and business-system integration](https://www.kodekinetics.com/service/api-development-integration/)
- [Discuss integration readiness](https://www.kodekinetics.com/contact/?interest=integration&source=integration-readiness-checklist)

## Version history

- 2026-09-28: Initial workbook, evidence prompts, mapping and failure worksheets, hypothetical example, and decision record.