What we built this week

Each bot now signs in with its own key, not a person's password.

When a bot needed to sign in, it used a person's email address and password, saved on the machine. That meant one person's credentials sat on every machine they had ever set up, and revoking access for one machine meant changing the password for everyone.

Now each bot connects with its own key. A person approves the connection once from the web, the bot stores its key in the operating system's secure keychain, and the password is deleted. If you need to cut off one machine, you disconnect it from the bot page and it stops within about thirty seconds, without signing anyone else out.

Bots already running will swap their saved password for a key on their own the next time they connect. The cut-off date for bots still using a password is 26 October 2026. Company admins will be reminded fourteen days and three days before, with a list of the machines still to move.

This change is also what makes compulsory two-step sign-in for admins possible, which follows in the same release.

Incident alerts now catch a process that keeps failing the same way.

The previous rule opened an incident only when a process failed three times inside one hour. Because the bot waits at least thirty minutes before retrying a failing process, a scheduled process could fail dozens of times over several days and nobody would be told.

We saw exactly that in late September, when one process failed about thirty times at the same step with no alert raised.

The rule now also opens an incident when the last three runs of a process failed in the same way, however far apart those runs were. A success, or a failure with a different cause, resets the count, so a process that fails once on a Monday and once on a Friday does not trigger anything. Runs the platform stopped itself for its own reasons are skipped and do not affect the count.

The alert message tells you the process has failed its last three runs in the same way, with no successful run in between, and names the first failure as the start of the incident. No database change is needed, and the update works with bots already in the field.

The risk and control register now has an overview, reminders, exports and AI help.

A risk register that lives in a spreadsheet is hard to act on. Owners miss review dates, auditors ask for evidence files, and nobody can see at a glance which controls are actually working.

This week we added four things to the Automize register that address all of that.

The overview page shows every open finding across the register, a heat map of risks before and after controls, which controls are failing in real automation runs, and how much of ISO 27001 Annex A and SOC 2 your register covers. A daily reminder goes to the owner when a risk review is due within seven days, or when a manual control has no sign-off within its period.

Auditors can now attach a proof file, such as a PDF or a signed document, directly to a control sign-off. Risk acceptances must be signed by a company admin and expire after at most twelve months, with a reminder two weeks before. The register exports to a spreadsheet, and you can import one from Excel to get started quickly. Three starter registers are included: an accounting firm set, a POPIA essentials set, and an ISO 27001 starter.

Email triggers can now skip out-of-office replies and bounce messages.

If your automation watches a mailbox for incoming invoices or requests, it has probably started unnecessary runs on out-of-office replies, delivery failures and read receipts. Those runs waste time, can fill a log with false activity, and in some cases have caused a process to loop.

There is now a switch on every email trigger and every unread-email loop: skip automatic replies. When it is on, the bot checks Outlook's message type, standard email headers and the subject line before starting a run. Messages that are clearly automatic, such as those with subjects like "Automatic reply" or "Out of Office" in nine languages, are moved to an "Automatic replies" sub-folder of the watched folder and left unread, so nothing is lost.

The switch is on by default for new triggers. Existing triggers stay off until you choose to turn it on, so nothing changes for processes already running. The bot page shows a count of automatic replies moved, alongside the trigger's normal waiting count.

A slow database query no longer blocks every bot from downloading its processes.

On 1 October, one database query hit its time limit on every process download, and because bots retry roughly every twenty seconds, the same query kept running on a database that was already under pressure. The result was that bots across the platform could not pick up their work.

The query in question works out which systems each process uses, so the bot can name the system a failing step was driving. It was reading far more data than it needed: it checked every application in the platform to find the ones belonging to the right company, and it fetched each step again for every signal it needed to match.

The rewritten query finds a company's applications from an index, reads each step once, and skips the work entirely when the company has no confirmed applications. It returns exactly the same result as before. On a database with production-scale data, the amount of data read drops sharply, which is what matters when memory is short.

The fix is in place and bots are downloading processes normally.