Stolen Orbit
ENIT
Let’s talk
FREE TEMPLATE · FILL IN, DOWNLOAD, REUSE

System integration map

Describe each connection as a contract between systems. This worksheet clarifies what may be read or written and what must happen when a request fails.

By Stolen OrbitRevision

When to use it and what to produce

When automation transfers data between existing tools and operations, implementation partners and IT need a shared specification.

One connection record containing field mappings, permissions, duplicate handling and a reconciliation check.

Fill in the fields below and download your document. The website does not send or save answers: closing the page may lose them. Examples are illustrative and should be replaced with your process data.

Download the complete blank template (.md)

1. Define the connection

Separate reads, creates and updates. A system available through a user interface does not necessarily provide the required APIs or permissions.

See a worked example

Illustrative example: an approved request creates an ERP order draft. The customer code comes from the ERP master record; a free-text company name is not sufficient identification.

Record test and production environments and a technical contact for each system.

Describe what triggers the transfer, when it runs and which record is created or changed.

Map identifiers, formats, units and precedence rules when the systems contain different values.

2. Limit the effects

Specify access and expected behaviour before connecting production credentials. Record references to secrets, never passwords or tokens in this worksheet.

See a worked example

Illustrative example: use the request identifier as an external reference. If a draft with that reference exists, verify its state before attempting another write.

List accessible resources and fields; specify actions that need human approval.

Define how repeated delivery of the same event is recognised without producing a second operation.

Document verified API, size, availability and version limits; label anything still awaiting confirmation.

3. Design recovery

A missing response does not prove that a write failed. Plan checks before repeating operations that can produce real effects.

See a worked example

Illustrative example: after a timeout, search for the draft by external reference. If its state remains uncertain, send the case for review instead of creating another order.

Separate temporary failures, invalid data and cases needing intervention; set bounded retry rules.

Specify which identifiers, counts or amounts are compared and how frequently.

Explain how to stop the flow, resume from the correct point and inspect effects already produced.

Pitfalls to avoid

  • Promising an integration before verifying actual access and system capabilities.
  • Retrying a write without checking whether it already happened.
  • Monitoring technical errors while missing absent or duplicate records.

Take the next step together.

Use this document to start a discussion about scope, evaluation and project ownership.

Review the text before sending. Only your email is needed alongside the message; other details are optional.