Observe before restarting

The official troubleshooting guide distinguishes waiting approvals, authentication problems, usage limits, routine configuration, and unreachable computers. It recommends recovery before reset, because a reset can lose recent unsynced work. A disconnected app does not necessarily mean cloud work has stopped.

The diagnostic questions below are an editorial way to narrow the problem; they do not establish the cause of any particular failure.

Documentation: Official troubleshooting guide ↗

Find the last confirmed step

Record what the Bot actually completed and the first thing it could not do. 'The report is broken' is less useful than 'the source opened, but the date filter did not apply.' A narrow description makes it easier to resume without repeating previous actions.

Avoid issuing the entire request again until you know whether the first run wrote anything. A retry can create a second draft, ticket, or message if the previous attempt succeeded just before the connection failed.

  1. Inspect the conversation and computer state for a question, approval, sign-in, or visible error.
  2. Ask for the last completed action, current blocker, and any external changes already made.
  3. If a source failed, test one small read before rerunning the full task.
  4. If authentication is needed, complete the supported human sign-in step and resume from that point.
  5. For an unreachable computer, follow the current official recovery sequence. Preserve available work before considering a reset.

Send a diagnostic redirect

This is useful when the Bot is repeating an approach without producing new evidence.

Try this brief

Pause the current approach and diagnose the blocker. State the last action confirmed successful, the first failing step, the exact visible error if any, and whether any external changes already occurred. Do not repeat writes or reset the computer. Suggest one small, non-destructive check that distinguishes missing access from unavailable data or a changed interface. If you need my input, identify the precise action I should take. Preserve partial results and link them here.

Original editorial template. Replace placeholders and review access before running.

If the issue is a routine

Check whether the scheduled occurrence exists in recent history, whether it started, and whether it finished. These are different failure classes. A run that started but produced no useful report calls for input and output inspection; a missing occurrence calls for schedule and enabled-state inspection. Verify the owner, time zone, source access, and account state before concluding that scheduling is unreliable.

  • Record the occurrence time with its time zone.
  • Keep the routine name and a redacted error or screenshot.
  • Record the app version and the checks already attempted.
  • Inspect any possible side effects before using a test run.

Leave the next run easier to diagnose

Add a small completion note to the workflow: input range, records inspected, artifact location, and unresolved steps. A normal empty result should explicitly say that no matching records were found. Silence is too ambiguous to distinguish success from a failed run.

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief ↗