Document integrations before the expert leaves

Start with the integration your team depends on most - the one that would cause real pain if it stopped working tomorrow. You want to capture everything someone would need to understand, troubleshoot, or rebuild this connection from scratch.

Why this matters: We've seen teams waste entire days trying to fix integrations because nobody wrote down how they were set up. When it's 2am and something's broken, you don't want to be guessing - you want clear instructions sitting right here.

What to document:

• The app name and what specific business problem it solves for your team
• Login URLs and the credential format (don't paste actual passwords here - use a password manager link instead)
• Every other system this app talks to, and how those connections work
• Any API keys or tokens the integration needs (note where they're stored securely)

Practical tip: Take a screenshot of the integration settings screen and attach it to this step. It'll save 20 minutes of confusion the next time someone needs to find the right config page.

 From experience: The integrations that cause the most headaches are the ones set up by someone who's since left the company. Don't let yours become one of those - document it now while you still remember the details.

Now it's time to document the supporting apps that extend or connect to your primary integration. These are the ones that often run quietly in the background - until they don't, and then nobody knows what broke or why.

For each connected app, capture:

• The app name and how it relates to your primary integration
• What data moves between them, how often it syncs, and in which direction
• Who currently has access, and who can grant or revoke permissions
• Known issues, quirks, and workarounds your team has discovered

Draw the data flow: Even a simple text description helps. For example: "Customer orders from Shopify sync to QuickBooks every 15 minutes via webhook. If the sync fails, orders queue up in Shopify and need to be manually exported as CSV and imported."

Practical tip: Pay extra attention to sync frequency and failure modes. The most common support calls we've seen are about data that's "stuck" between systems because a scheduled sync silently failed.

Duplicate this step if you have multiple supporting integrations to document. Each one deserves its own clear record so nothing gets buried in a long, single document.

 From experience: Teams often forget to document the apps that "just work" in the background. Those are usually the ones that cause the biggest surprises when they break, because nobody even remembered they existed.

You've written it all down - but does it actually work? Before you call this done, have someone who wasn't involved in the setup try to follow your documentation. If they get stuck, that's where your docs need more detail.

Quick verification checklist:

• Can a new team member log in using the documented credentials and access paths?
• Do all the links, download URLs, and config page references still work?
• Is data actually syncing between apps the way you described?
• Have you walked through the troubleshooting steps for at least one common issue?

Set a review schedule:

Integrations change all the time - vendors update APIs, your team switches tools, permissions get reshuffled. Set a calendar reminder to review this documentation every 3 months. Record the review date below so the next person knows when it was last checked.

Key contacts for when things go wrong:

• Technical problems: Who on your team actually fixes broken integrations?
• Access requests: Who approves new user access to these systems?
• Billing questions: Who handles subscription renewals and payment issues?

Practical tip: The best test is to hand this documentation to your newest team member and ask them to explain the integration back to you. If they can do it, your docs are solid. If they can't, you've found the gaps.

This is the step that's easy to skip but painful to regret. Before any integration goes live (or gets formally documented as existing), you need to make sure it meets your organization's security standards. Every integration is a door into your systems - you want to know exactly what's behind each one.

Security checklist:

• Does this integration use OAuth, API keys, or something else? Where are those credentials stored right now?
• What data does it have access to? Flag anything that's personally identifiable (PII) or sensitive business data.
• Does the vendor hold SOC 2, ISO 27001, or similar certifications? (Check their trust/security page.)
• Is data encrypted both in transit (HTTPS) and at rest on their servers?

Access control:

• Who originally approved this integration, and is that approval documented anywhere?
• What happens to this integration's access when an employee leaves? Is there a clear offboarding step?
• Are permissions set to the minimum needed? (If the app only needs to read contacts, it shouldn't have write access to your entire database.)

Compliance notes:

If your organization handles data covered by HIPAA, PCI-DSS, or GDPR, write down any special requirements for this specific integration. Link directly to the vendor's compliance documentation page - don't just say "they're compliant," point to the proof.

 From experience: The number one security issue we've seen with integrations isn't hackers - it's former employees who still have active API keys or OAuth tokens. Make revoking access part of your standard offboarding checklist.