Integration checklist before implementation

Name one source for every data item

Decide where each item is created and maintained. A customer email may appear in several places, but one must be the primary source.

Also name the business owner who decides which value is correct.

Do this

1. List transferred data in plain language.
2. Name the primary system for each item.
3. Name the person or role that resolves conflicts.

Describe the data format with an example

A field name does not fully describe its contents. Add an example, whether it is required and allowed values. Record whether it can change later.

Pay special attention to identifiers. Names are rarely enough to match records between systems.

Check at least these

• Field name and clear description.
• Example of a valid value.
• Required or optional.
• Allowed values and length.
• Stable identifier for matching.

Decide when data must move

Not everything needs to move immediately. If an hour's delay is acceptable, a scheduled transfer may be easier to monitor and recover than a continuous real-time connection.

Also record event order and dependencies.

Do this

1. Name the event that starts transfer.
2. Set the acceptable delay.
3. Record what must exist before transfer.
4. Decide how late data is handled.

Design failure before success

Describe what happens when the connection fails, data is incomplete or the receiving system rejects a value. The integration must preserve what failed.

Retry automatically only for temporary errors. Invalid data needs a person, a visible reason and the item to correct.

Check at least these

• The error is stored with a clear reason.
• A temporary error can be retried.
• Invalid data is routed for correction.
• A retry does not create a duplicate result.

Limit access and visible data

Transfer only what the work needs. Limit permissions by action and data, and record what the credential is used for.

Do not use one person's account as a permanent technical connection. Assign ownership, storage and rotation before launch.

Do this

1. List data the connection reads and writes.
2. Remove unnecessary permissions.
3. Name the technical credential owner.
4. Agree rotation and closure.

Test one data flow and assign maintenance

Test the routine case, missing data, a broken connection and the same event twice. Users must see either the correct result or a clear error.

After launch, someone monitors transfers, responds to failures and approves changes when either system changes.

Check at least these

• The routine case transfers correctly.
• Missing data stops safely.
• A connection failure is visible and recoverable.
• A duplicate event creates no duplicate result.
• Monitoring and change owners are named.