# Integration handover template

One page per production integration. Fill in the systems, records, schedule, credentials, failure modes, escalation contacts and the date someone last verified it, from what runs today rather than from the original build specification. The count of fields filled in, shown at the side, updates as you go.

## How to use this template

Fill it in once per integration: download your answers, then choose Start again for the next one. Every field should describe production behaviour as observed, so where the answer is "we think" rather than "we checked", write that down and schedule a check. The example rows show the level of detail that is useful. Replace them with your own.

## Systems and direction

Fill in the entry column; the guidance column says what belongs in each field.

| Field | Guidance | Entry |
|---|---|---|
| Integration name | Example: CRM to commercial system, account and order sync |  |
| Source system |  |  |
| Target system |  |  |
| Direction | One way, two way, or one way with exceptions (list the exceptions) |  |
| Conflict rule for two way sync | Example: target system wins on address fields, source system wins on consent |  |
| Hosting environment | Where the code runs, who owns that environment, and any known decommission date |  |
| Code location | Repository or server path, and who has access |  |
| Business owner | The person who notices when it stops |  |
| Technical owner | The person who can change it |  |

## Records and fields

Replace the example rows with your own.

| Record | Fields that cross | Mapped or transformed | Direction | Notes |
|---|---|---|---|---|
| Example: Contact | email, first name, last name, company, consent status | consent status converted from text to a flag | CRM to commercial system | Contacts without a company are skipped |
| Example: Order | order number, account reference, line items, status | status values translated between the two systems | commercial system to CRM | Cancelled orders are not sent back |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

## Schedule

One row per trigger, with the example rows replaced by your own.

| Trigger | Frequency | Window | Typical volume | Watched by |
|---|---|---|---|---|
| Example: Scheduled batch | Nightly | 02:00 to 03:00 local time | A few hundred records | Job log, checked by the technical owner each morning |
| Example: Event | On record creation | Immediate | Tens per day | Alert on repeated failures |
|  |  |  |  |  |
|  |  |  |  |  |

## Credentials

One row per credential the integration uses; the grey text shows what belongs in each column.

| Credential | Where it is stored | Owner | Expires on | How it is rotated |
|---|---|---|---|---|
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

## Failure modes and symptoms

Describe each failure as it looks from outside, not as the code sees it, replacing the example rows with your own.

| Failure mode | What it looks like from outside | How it is detected | First response | Fallback |
|---|---|---|---|---|
| Example: Target system unavailable | Records are delayed, then arrive in a batch | Alert after three failed attempts | Check the target system status page before touching the integration | Records queue and replay automatically |
| Example: Record fails validation | A single record is missing in the target and nobody is told | Weekly count comparison between systems | Fix the record at source and rerun | None, manual entry |
| Example: Credential expired | Every record fails from one date onwards | Alert on the first failure | Rotate the credential per the table above | None |
| Example: Hosting switched off | Nothing arrives, no errors anywhere | Business owner notices missing leads | Confirm with the hosting owner, then restore from the code location | Old environment, if still reachable |
|  |  |  |  |  |
|  |  |  |  |  |

## Escalation

The three levels are filled in as a starting point; change them to match your arrangement.

| Level | Contact | Reach by | Expected response |
|---|---|---|---|
| First | Technical owner | Chat or phone, not a ticket queue | Same working day |
| Second | Supplier or internal platform team, named person | Named contact, support pool reference if one exists | Agreed in the support arrangement |
| Third | Business owner of each connected system |  | Decision on manual workaround |
|  |  |  |  |

This is the field that changes behaviour. A page with no verification date in the last quarter describes an integration in an unknown state, and unknown is the state that produced the emergency.

## Last verified

| Last verified on | Verified by | What was checked | Next check due |
|---|---|---|---|
|  |  | Records crossed as listed, schedule ran in the window, one provoked failure produced the alert |  |

Put the next check date in a calendar that belongs to a role, not a person, and store the completed page where the people who receive the alerts can find it.