Review desk for portal forms your team still fills in by hand

Build me a review desk for filing records into websites that have no API: the supplier portals, registration sites and claim forms my team still types into by hand. The app is where a back office coordinator works all day, so the queue is the main screen, not a notification.

The queue view reads rows from a Google Sheet using Get Values, one row per record to file. Each row carries the target site, the field values to enter on that site, an owner, and a status of queued, prepared, awaiting review, submitted or failed. Show these as a table with the status clearly marked, and give me filters by target site and by owner so a coordinator can narrow to just their own work or just one portal. Sort so the rows that need attention, prepared and awaiting review, sit at the top.

Each row has a Prepare button that kicks off a background agent. The agent opens a Kernel browser session with Create Browser Session, attaching our saved login profile so it picks up an existing signed-in session rather than handling credentials itself. It navigates to the target form and fills every field from the row using Type Text in Browser, Click Mouse in Browser, Press Keys in Browser and Scroll in Browser, batching runs of actions with Execute Batch Computer Actions where that is faster. It must deliberately stop before the final submit button. It then takes a screenshot of the completed, unsubmitted form with Capture Browser Screenshot and returns it to the app, where it lands on the row and the status becomes awaiting review.

The review screen shows that filled-form screenshot side by side with the source row from the sheet, so the reviewer can check each typed value against the record it came from. The reviewer either approves or rejects with a note. Approving tells the agent to click the submit button, wait for the result page, and capture the confirmation screen with Capture Browser Screenshot, reading the confirmation or reference number off that page. Rejecting writes the note onto the row and sends the status back to queued so it can be corrected and prepared again.

On a successful submit, write the confirmation number and a submitted timestamp back to the sheet with Update Values, mark the row done, and keep the confirmation screenshot attached to the row as the audit trail. The confirmation screenshot is the proof a filing happened, so it should stay visible on the row after submission rather than being discarded.

The business rule I care most about is absolute: nothing is ever submitted without a human approving the screenshot first. The agent that prepares a form has no path to clicking submit on its own. Submission only happens on the approve action, on a row that already has a reviewed screenshot. Build the app so this cannot be bypassed, including by the Prepare all queued button.

Give me a Prepare all queued button that works through every queued row so a batch can be staged overnight and reviewed in one sitting the next morning. It should prepare rows one at a time, respecting the browser session limits on the account, and leave each one filled in but unsubmitted. Show progress as it goes and do not let one failing row stop the rest of the batch.

Handle the browser session lifecycle carefully, because a prepared form has to survive the gap between staging overnight and review the next morning. Give prepared sessions a generous idle timeout, and when a reviewer approves, first check the session is still alive with Get Browser Session. If it has expired, do not guess or submit blindly: mark the row so the reviewer knows it needs preparing again, and re-run the prepare step to produce a fresh filled form and screenshot for approval. Close sessions with Delete Browser Session once a row is submitted or rejected, so we are not paying for browsers nobody is using.

When a prepared batch is waiting on a reviewer, send a Slack message with the Slack Bot Send a Message operation saying how many rows are ready and which sites they are for, with a link back to the app. Send this once per batch rather than once per row, so an overnight run produces one message in the morning instead of fifty.

If the agent cannot find a field, the form has changed, or the site errors out, mark that row failed with a short reason and keep it in the queue rather than guessing at values. Failed rows should be visible in the same view with their reason, so the coordinator can fix the underlying row and prepare it again.