The Switch

Revoking the integrations you forgot

At some point you connected the assistant to your storage, your calendar, your mail, or your code hosting. Cancelling the subscription does not reliably remove those authorisations, and deleting the account does not either — because they are not held by the assistant, they are held by the other service.

Revoking them is part of leaving, it happens in a set of places you are not thinking about, and nothing prompts you to do it.

Why cancellation does not handle this

An authorisation is a grant stored in the service being accessed, not in the thing doing the accessing. When you connected your storage, your storage recorded that this application may act on your behalf. That record lives with your storage provider and it has no idea what happened to the subscription.

Whether closing an account triggers any cleanup varies by product and is not something you can verify from outside. Treat it as: nothing was revoked unless you revoked it, and check the other side rather than assuming.

Make the list from your side

Two passes. First, whatever the old account shows for connected apps, integrations or connectors — that is the inventory as the assistant understands it.

Second, and more reliably, go to each service you actually use and look at its own list of authorised applications. Most services have a security or connected-apps area of account settings that lists every third party holding a grant, with the scopes and often the date.

The second list is the one that matters, because it is the list that will still exist after the assistant account does not. It is also usually longer, and includes things you connected once during an experiment in a week you have forgotten.

Where to look

The categories worth checking, in rough order of how much access they carry:

  • cloud storage and document services
  • mail and calendar
  • code hosting
  • chat and team communication platforms
  • project tracking and note-taking tools
  • anything you signed into using a single-sign-on provider

For each, open the connected-applications or authorised-access area of the account settings and read the list. You are looking for anything naming the assistant you are leaving, or a plugin or connector related to it.

This is a twenty-minute pass and most of the entries will be unrelated to this switch — which is its own useful outcome.

Revoke, and read the scope on the way past

Before revoking each one, read what it was allowed to do.

This is worth the extra five seconds because it tells you what to check afterwards. A grant that could only read files means nothing further to do. A grant that could write, delete, or send needs a quick look at whether anything unexpected happened, and needs whatever the assistant created to be accounted for before the connection goes.

Then revoke. Revocation takes effect immediately and is generally safe to reverse by reconnecting, which makes it the least dangerous step in the whole switch.

Two things revoking does not delete

Anything created through the integration stays where it was created. Documents written into your storage, calendar entries, commits, messages sent — all of that belongs to the destination service now and is unaffected. Revoking removes future access, not past effects.

Data the assistant already ingested is a separate question, governed by the old account’s retention rather than by the integration. That belongs to what happens after the account closes, and revoking a connector does not accelerate it.

What moves

WHAT MOVES — integrations

  · Files, events and messages the
    integration created
                    → stay where they were created.
                      Unaffected by revoking.

  · The authorisations themselves
                    → STAYS BEHIND, live, in the other
                      services. They do not expire on
                      their own.

  · The connector setup on the new side
                    → STAYS BEHIND. Every integration is
                      per-product and gets reauthorised
                      by hand.

  · Automations built on the old connection
                    → STAYS BEHIND. They fail silently
                      when access goes.

  · Deleting the old account without
    revoking
                    → IRREVERSIBLE loss of the inventory.
                      The grants persist and you no
                      longer have a list of them.

Do the new side separately, and deliberately

Reconnecting the same set of integrations on the new assistant is the default and is worth resisting for a moment.

Connect what you actually used during the parallel period, when it becomes necessary — not all of them on day one from the old list. Half of the old connections were configured once, used twice, and left in place, and a switch is the cheapest chance to not carry them.

Grant the narrowest scope offered. Read what is being requested. You are creating the exact grants that somebody in your position will be hunting for the next time, and the smaller the list, the shorter that hunt is.

What is genuinely lost

Anything automated on top of the old connection. A scheduled job, a workflow in another tool, a recurring task that depended on the assistant being able to reach a service — those break when access is revoked, and they break quietly rather than with an error you will see.

Nothing enumerates them. You find them by noticing that something stopped happening, usually a few weeks later, which is why the ones you care about are worth writing down while you can still see the integration that supported them.

accountscancelling