Help Centre › Troubleshooting & FAQ
When a run fails, Automize tells you which step failed, what the bot said, and, with a recent bot, why it thinks it failed. This article shows where to find each of these and what to do next.
1. Right after the run
When you start a run from the website, for example from the Launchpad, a tracker opens and follows it. If the run fails, the tracker shows:
- Failed at step: the name of the step it stopped on.
- What happened: what the bot reported.
- Why: the bot's own reading of the cause (see below). When it is not sure, it says "the bot thinks …, but is not sure."
- What to do: the next thing to try.
- Open the step: opens the process map on that step, inside a sub-process if that is where it is.
2. The bot works out why on the machine
When a step cannot find what it is looking for (a button, a field or a window), a bot from version 6.8.6 looks at the screen before it gives up. It then sends Automize only its answer, never what was on the screen. The answer is one of these:
| The bot says | What to do |
|---|---|
| The screen was slow: what it looks for turned up just too late | A longer wait. The supervisor can try this for you. |
| What it looks for has changed on the screen | Open the step and pick the control again, or accept a backup selector if one is offered. |
| What it looks for is no longer on the screen it expects | The application may have changed. Check the step still has something to do here. |
| It was on the wrong screen | The step before did not do its job. Look at that step. |
| A pop-up was in the way | Add an answer for the pop-up, or a step that closes it. |
| The application was not open or not responding | The machine or the application, not the process. Check the bot's machine. |
| It was logged out or refused access | Check the login details and whether the account is locked. |
| The input data was missing or wrong for this step | Check the input file or the item it was working on. |
| It could not tell why | Look at the error and the screenshot yourself. |
The bot only does this for failures nobody planned for. A step with an error route, continue on fail, or inside a Try-Catch is left alone, and so is a debug run.
Before it gives up, the bot also waits a little longer for the missing control. If it turns up, the step runs once more and the run carries on.
3. The Runs tab on the process
Open the process and choose the Runs tab. At the top, Why it keeps failing lists the steps worth fixing, with what the supervisor suggests. Below it:
- Failing steps lists every step with an open error, worst first. A red badge on the map means the same. Details opens the step's Errors: the kind of failure, What the bot said, a picture of What it saw next to What it expected, and what to do.
- From the errors you can Acknowledge (you have it), Mute 24h, Resolve (it re-opens if the fault comes back) or Resolve all.
- Insights shows advice the bot gave for a past run, such as a lookup that matched no rows. Acknowledge hides one on future runs of the process; Show acknowledged brings them back.
For more on the Runs tab, see Running and debugging a process.
4. Diagnose with AI
In a step's Errors, click Diagnose with AI. The AI reads the step's open errors, their history, the failure screenshot and what the step was recorded against. It answers with a Root cause, how sure it is, and Suggested steps.
Where it can, it also proposes a Proposed configuration change to the step. Apply fix saves it through the normal edit, so it shows in the process's Changes. The message that follows has an Undo.
It is part of AI-powered actions, on plans that include them.
5. Pick the element on a copy of the page
When a browser step cannot find its button or field, you would normally have to open the website again to fix it. With page copies switched on, you don't.
- An administrator switches on Keep a copy of the page when a browser step fails in Settings › Privacy and data › Bot privacy. It is off until someone does. It needs bot 6.8.7 or later.
- When a browser step fails, the bot keeps a picture of the page and the names of what was on it. Every field with something typed in it is greyed out first.
- On the failed run in the Runs tab, click Pick the element. In a debug run the same button shows on the failed step's banner.
- Click the right element on the picture, then Use this element. The step is saved with it. Undo the last pick puts it back while nobody has changed the step since.
In a debug run, the bot then retries the step with the new element straight away.
If the only way to find the element is by its position (for example "the 4th Pay button"), Automize warns you. That kind of selector picks the wrong row once the list changes.
A bot takes at most 3 copies a run, and none for a step marked sensitive. Only people who may edit the process can open a copy. Copies are kept 90 days.
6. Send more detail to get better suggestions
Send what was on screen when a step fails, in the same settings, lets the bot send the ids and types of the controls near the one it could not find. The supervisor uses them to suggest a better fix. It never sends the text on the screen or what was typed, and numbers inside ids are blanked. It is off by default.
What each of these settings sends and how long it is kept is in Privacy and data.
7. When a failure becomes an incident
One failure is often cleared by the next run. When the same failure repeats, Automize opens an incident and shows a red banner on the process: This automation is failing, with how often and since when.
- A normal process opens one after three of the same failure within an hour, or three failed runs in a row.
- A High care process opens one on the first real failure, alerts its owner at once, and escalates if nobody acknowledges it. Set this under Edit › Care level on the process.
- Bad data never opens an incident.
On the banner, Acknowledge makes you the owner and stops it escalating. Resolve clears it; the next failed run opens it again if the fault is still there. See what is failing opens the Runs tab.