Rotate automation credentials without losing incoming work

Inventory uses before changing access

List every workflow using the connection, including scheduled runs, manual tools and retries of old failures. A shared connection can affect work that is not visible in the workflow currently being edited. Record the destination, required operations, owner, expiry and dependent workflows without copying the secret value into the inventory. If the connection belongs to an individual, decide whether the business needs an organization-controlled identity. Do not replace access whose owner or purpose is unknown merely because the name looks obsolete.

Match the required permissions

Check the actual tables, folders and operations the new identity needs. Separate reading, creating, updating and notification permissions instead of granting broad access to make an error disappear. Success in a test folder does not establish access to the live destination, and access to unrelated departments is not a useful feature. OAuth reauthorization and API-key replacement follow different procedures, so use the documentation for the active method. Keep the permission comparison alongside the workflow inventory so a reviewer can see what changed.

Choose a controlled cutover window

Find out whether the old and new credentials can coexist or whether replacement invalidates the old access immediately. Coexistence does not justify sending the same request through two active workflows. Compare holding intake for later processing, a short pause and a staged switch by business process. State where paused data remains and verify its limits and retention. Assign someone to watch intake during the change and define the point to which a rollback returns. The selected method should fit the business’s tolerance for delay.

Verify the complete required operation

A successful reauthorization message is not an end-to-end test. Use fictional intake to verify every required search, creation, update and notification. Look for the case where reads succeed but writes fail, and inspect the resulting author or change history where relevant. Trace the work with identifiers and outcomes rather than logging authorization headers or key values. Include manual recovery operations in verification: an operator may need permissions that an ordinary successful run never exercises, especially when correcting or replaying an unfinished request.

Retire old access after checking dependencies

Old failed executions may still reference the former connection after normal runs have switched. Inspect unfinished and running work, and check evidence of recent use before retirement. Name the person approving retirement and revoke unnecessary access at the destination as well as in the automation editor. Do not remove a documented rollback option while its approved window remains open. After revocation, verify an ordinary run and a recovery path, then search the inventory for remaining references rather than assuming that removal from one screen is sufficient.

Keep a rotation and recovery record

Keep the connection name, affected workflows, cutover time, verification results and retirement status in the rotation record. Shared documentation does not need the secret itself. Assign the next owner and review date, with additional checks when staff or permissions change. A wider staff handover must also cover billing, unfinished work and escalation contacts; credential replacement alone does not transfer operational responsibility. Ask another operator to use the record to distinguish an authentication failure from an invalid input and identify the safe next action.

• Hand over automation accounts, connections and unfinished work
• Choose webhook automation around duplicates, order and replay