Fix Make connection and permission errors: verify, reauthorize and replace

Record the failing operation and connection

From execution history, note the module, time, error details, connection name and destination resource ID. Do not diagnose from an HTTP status alone; read the service’s explanation. Keep access tokens and customer payloads out of a shared incident note. A small record containing the relevant IDs and failure category is usually more useful for tracking the repair.

Verify access and inspect dependencies

Open Credentials > Connections, locate the connection and use Verify. Review its granted permissions and the scenarios that use it. Check for similarly named accounts: a practice connection or personal account can look correct while targeting the wrong workspace. Use clear names so an operator can tell which account and environment a workflow depends on.

Check permission on the specific resource

A connection may read sheet A while lacking access to sheet B in another shared drive. Check whether its account can open the exact resource and perform the required read or write. An incorrect ID, deletion, move or changed sharing policy can resemble an authentication problem. Identify the missing operation before choosing a broader permission change.

Reauthorize OAuth with the intended account

When OAuth access needs renewal, choose Reauthorize and follow the prompts using the correct account. Check whether the browser blocks the authorization window. Google documents several reasons refresh tokens can stop working, including revoked access, some Gmail-related password changes and administrative restrictions. Avoid assuming that every provider or connection expires after the same number of days.

Review impact before editing keys or scopes

A shared connection can serve several modules, so changing it can affect more than the failing scenario. Record dependencies before updating a key or scope. A different account or authentication method may call for a new connection. Distinguish old and new connections and verify required operations before deleting anything that may still be used elsewhere.

Check required actions with isolated data

Test the smallest necessary reads, writes and notifications against practice resources. A successful Verify is not proof that every module has all required permissions. Before resuming production work, search for already completed effects by source ID. Reauthorization repairs access; it does not by itself establish whether an earlier intake was saved or its notification delivered.

Escalate policy restrictions with useful evidence

If the provider’s organization blocks an integration, repeating consent prompts will not remove that policy. Give an administrator the integration name, required operation, resource and failure time. Request the access needed for the task rather than indiscriminately widening permissions. Define temporary manual intake and source IDs for later reconciliation while the decision is pending.

Leave an ownership and recovery record

Record the connection changed, reason, affected scenarios, checked operations and remaining IDs. Put personally owned accounts on the handover list before staff access is removed. These are official-source diagnostic steps and suggested acceptance checks, not a claim that this article has repaired or executed a workflow using your connected accounts.

• Recover unfinished work after checking completed effects
• Hand over connections and operational ownership
• Review the email-to-sheet workflow
• Plan credential rotation across automation systems