An AI workflow may connect to email, document storage, a shared workspace, or another approved business tool. When that connection is retired, changing vendors, removing access, and preserving useful operating knowledge are different jobs. Revoking a token can stop access, but it does not tell the next operator which sources were authoritative or how exceptions were handled.

This guide helps United States small businesses close one AI tool connection while keeping a readable, vendor-neutral workflow record. It does not promise that every vendor supports the same export or deletion controls, and it is not legal advice about retention. Local AI Developer builds scoped systems with documented memory and approval boundaries, including Los Angeles County workflow projects; the frequently asked questions explain important local and cloud processing limits.

Define exactly what is ending

Name the connection, not just the product. A business may stop one assistant's access to a shared drive while continuing to use the same vendor for unrelated work. Record the account owner, connected resource, permission purpose, workflow that depends on it, and intended shutoff date.

Distinguish four possible changes: removing a person's access, revoking an application connection, retiring a workflow, and closing a vendor account. They have different consequences. Closing an account before exporting required records may create avoidable loss; removing one operator may leave an application token active.

Assign an offboarding owner and a business approver. The owner performs and records the steps. The approver confirms that the workflow can stop or move without breaking an important handoff.

Freeze changes during the handoff

Choose a short change window in which operators do not add new rules, sources, or destinations to the retiring workflow. Continue necessary business work through an approved fallback, but avoid editing the old procedure while someone else is documenting it.

Capture the last expected input and output identifiers. Note any items still waiting for review, retries, or manual action. A clean cutover record prevents an unfinished draft from being mistaken for completed work after the connection is removed.

Tell affected operators where new work should go. The message should identify the replacement route or manual fallback and the time the old connection stops being valid. It should not include credentials or technical secrets.

Separate instructions from vendor configuration

Business instructions should explain the workflow in terms a person can inspect: purpose, approved sources, required fields, transformation rules, output structure, reviewer, hold conditions, and prohibited actions. Vendor configuration may express some of those rules in prompts, automation steps, or tool settings, but the configuration is not the only readable record.

Create a vendor-neutral procedure before dismantling the old setup. Replace interface-specific phrases such as “click this bot” with the business event and expected state, while retaining a separate appendix for current technical implementation details.

Do not copy an entire conversation history and call it documentation. Chats can mix case facts, accidental corrections, sensitive information, and obsolete guidance. Extract only reviewed rules and representative examples, and identify the person authorized to approve them.

Inventory data and records

List what the retiring connection could read, create, or change. Include source folders, mailboxes, calendars, task lists, generated files, logs, saved prompts, workflow states, and review queues. Mark each item as business record, temporary working data, system configuration, credential, or replaceable software.

For each business record, identify its owner and approved destination. Preserve records according to the business's actual policy and applicable obligations; do not invent a retention period. If policy is unclear, hold deletion and route the decision to the responsible owner.

Record whether the vendor offers exports, activity logs, account deletion, or connection revocation. Verify current controls in the vendor's own documentation and account interface. An export may omit configuration, deleted history, or third-party records, so document what was actually obtained rather than assuming it is complete.

Preserve source ownership and decision rules

A useful procedure names the source of truth for each important field. “Check the shared drive” is not enough when several versions exist. Record the exact resource, business owner, method for recognizing the current version, and what happens when sources conflict.

Preserve decision rules separately from examples. A previous output may illustrate format, but it should not silently define policy. Write the condition, required action, expected result, and escalation owner for each rule that affects a commitment, permission, or external communication.

Capture stop conditions. Missing identity, stale source material, conflicting instructions, or an unavailable reviewer should cause a visible hold. The replacement workflow must not infer that the old connection had authority simply because it previously produced an answer.

Export only what is useful and approved

Before exporting, decide which records are required for continuity and which should remain in the source system. Bulk exports can create a second unmanaged copy of sensitive data. Use the smallest approved set that supports audit, transfer, or rebuild needs.

Place exported files in an organization-controlled destination with an owner and access boundary. Record export date, source account, scope, file format, known omissions, and integrity check when appropriate. Keep credentials and access tokens out of the export package.

Test readability outside the retiring product. A proprietary file that no authorized person can open is weak continuity evidence. Where practical, preserve critical instructions in a durable, readable format while retaining original exports when policy requires them.

Map every permission before revocation

Create a connection register with application name, account, resource, permission scope, business purpose, approval owner, and revocation method. Include indirect access such as delegated mailboxes, shared links, API keys, service accounts, browser sessions, and automation webhooks when they are part of the scoped workflow.

Do not assume deleting a local application revokes cloud access. Use the account provider's current security or integration controls to remove the authorization. Likewise, changing a password may not revoke every active token. Follow the actual vendor and identity-provider instructions.

Plan the order. Stop scheduled jobs, preserve approved records, confirm the fallback, revoke the connection, remove unneeded local secrets, and then test that access is gone. If order matters for the specific vendor, document and follow its supported process.

Rebuild without carrying hidden authority forward

If a replacement workflow will be created, start with the vendor-neutral procedure and approved sources. Do not clone every permission from the old system. Ask what the new implementation needs for one bounded output and grant only the approved access for that purpose.

Reauthorize connections through organization-controlled accounts. Record who approved each permission and when it should be reviewed. A replacement tool should not inherit posting, sending, deletion, or administrative authority merely because the old tool had it.

Use representative test data before live business records. Verify output structure, source references, hold behavior, review destination, and manual fallback. Keep external sending or record-changing actions disabled until separately tested and approved.

Verify that offboarding worked

Run checks from both sides. In the business account, confirm the application authorization, token, shared link, or service identity is removed as intended. In the retired application, confirm it can no longer retrieve the protected resource. Record date, tester, method, and observed result without storing a secret.

Check scheduled activity after revocation. A failed job may continue retrying and filling a queue even though access is gone. Disable obsolete schedules and alerts, then confirm the replacement or manual process owns new work.

Review remaining local files and logs. Remove credentials through the approved secure process. Retain business records only where policy permits, and document unresolved deletion or vendor-account actions for the responsible owner.

Run a continuity test with a new operator

Give an authorized backup operator the preserved procedure, approved source access, and a controlled case. Do not provide the old chat history or undocumented coaching. Ask the operator to identify the current source, produce the expected draft, recognize one hold condition, and route it for review.

If the operator cannot complete the test, determine whether the missing piece is a business rule, source ownership fact, technical setup step, or credential process. Add the missing approved information to the correct record. Do not solve continuity by restoring unnecessary access to the retired tool.

Compare the test result with explicit acceptance criteria. Record what passed, what remained blocked, and who accepted the final handoff.

Keep a compact offboarding record

For one connection, retain:

Review this record when you compare scoped system packages. A well-documented offboarding process protects two assets at once: the business removes access it no longer needs, and it keeps the readable knowledge required to continue the workflow under accountable control.