What we built this week

Bots can now translate values on the fly using your own lookup tables.

Every organisation has a translation problem: the supplier name on an invoice is never quite the code your finance system expects. Until now, someone had to map that by hand on every run, or build a workaround into the process.

Automize now has lookup tables. You build a table in the Library - source value on the left, target value on the right - and add a "Look up value" step to any process. The bot reads the invoice, finds the supplier name, looks it up, and passes the right code straight to your finance system.

When nothing matches, the bot records the miss in the table with an empty target. A designer fills it in, and the next run finds it automatically. You can upload rows from a CSV or Excel file, search and edit them on a full page, and chain up to three tables so a miss in one falls through to the next.

The table page shows every process that reads it, every value the bot could not match, and a full audit trail of who changed what. Misses sort to the top so nothing waits unnoticed.

The supervisor now fixes broken selectors and asks what to do with unknown pop-ups.

Two things used to stop a bot silently and wait for a person: a button that moved on screen after a software update, and a pop-up the bot had never seen before.

The supervisor - available to companies that have switched it on - now handles both. When a step's main selector stops finding its button but a backup finds it, the supervisor proposes swapping them. It tries the change on the next few runs, keeps it only if nothing gets worse, and lets anyone undo it from Run History. It asks before acting, unless your company has allowed it to act on its own on steps where it is safe to do so.

When a pop-up appears that matches no known rule, the bot reports it: title, window type and button labels. The owner sees it in Run History, picks a button or chooses to stop the run, and the bot uses that answer the next time the same pop-up appears.

Both features are off until a company switches the supervisor on.

WhatsApp templates, sending and replies now work end to end.

The WhatsApp workflow - templates, outbound messages and replies against the kanban board - had been built but could not actually run. An audit found the blocker: a number registered through the product could never become active, so it could never send or receive.

A new activation step verifies the number using the same credentials every send uses, checks that the sub-account is open, and marks it ready. The settings page now tells you clearly what it can and cannot confirm about sender approval, rather than implying everything will happen on its own.

Offboarding is also fixed: previously, closing a sub-account left a billable number live at the provider. That is now released correctly as part of the close.

If your company uses WhatsApp for customer communication, speak to your Automize contact to get the workflow enabled.

Bot screens no longer bleed across pages, and clicks no longer multiply after repeated visits.

A subtle but serious problem was found and fixed this week. Because Automize changes pages without a full reload, scripts from a page you had left kept running in the background. The effects were visible: a bot's live screen could appear inside a different bot's viewer, a dialog answer could be sent to the wrong bot, and a screenshot request could pop up on whatever page you happened to be on.

The process map had the same problem with keyboard shortcuts. After visiting several maps, one Ctrl+Z could undo several changes across different processes. Visiting a bot page repeatedly caused each click to send multiple commands - or make multiple AI calls - because the handler was added again on every visit.

All of these are fixed. Timers, live connections and page-wide listeners now stop the moment you leave a page, whether you navigate forward, go back, or use the browser history. Pool, queue, job, credential and application pages are covered too.

Bots recover from a slow server at start-up, and report exactly why a browser frame failed to load.

Two improvements this week make it much easier to understand and recover from failures that used to look like dead ends.

First, if a bot cannot reach the server when it starts up — because the server was slow to respond or briefly unavailable - it now retries automatically. Waits start at 15 seconds and grow to every 5 minutes. A wrong password is never retried, to protect the account. Previously, one missed response at start-up meant the bot sat signed out until someone intervened by hand.

Second, when a browser step cannot find its element, the bot now checks whether the page contains any embedded frames that did not load. If one is found, the error in Run History names the frame's address and reports whether the relevant port answers from the bot's machine. An error that previously read "Element not found" now reads something like "The embedded frame did not load - port 8443 did not answer from this machine, but port 443 on the same server did, so a firewall or VPN is probably blocking it." That turns a mystery into a specific conversation with your IT team.