# 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.

Revision: 2026-09-24

## When to use it

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

## Expected output

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

## 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.

### Source, destination and owners

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

________________

### Trigger, frequency and operation

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

________________

### Fields and authoritative source

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

________________

> Illustrative example, replace with your own: 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.

## 2. Limit the effects

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

### Allowed and prohibited operations

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

________________

### Identity and duplicate handling

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

________________

### Limits and dependencies

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

________________

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

## 3. Design recovery

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

### Errors, retries and expiry

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

________________

### Source-to-destination check

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

________________

### Recovery and owner

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

________________

> Illustrative example, replace with your own: 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.

## 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.

Stolen Orbit — https://stolenorbit.com/en/templates/integration-map/