Let your ops team run browser automations without engineering

I want an internal app, a browser task library, that lets anyone on our ops team run a saved browser automation themselves instead of asking engineering to run it for them. It is built on Anchor Browser for the automations and Google Sheets for the run log.

The main screen is a two column layout. On the left, a library list of every saved automation loaded with Anchor Browser List Tasks (Legacy), one row per task showing the task name, its description, the time it last ran and the result of that last run. The last run time and last result come from List Task Executions (Legacy) for that task. Give every row a Run button, and let people search the list by name and sort by name or by most recently run.

Clicking Run calls Run Task by Name (Legacy) and opens the results panel on the right hand side. While the run is in progress show it as running, with the task name and the start time, and fill the panel with the returned output as soon as the run comes back, keeping plain text readable and showing structured output as formatted JSON. Show a clear success or failure state at the top of the panel. When a run finishes, append one dated row to the Google Sheets run log with Append Values, recording the date and time, the task name, who ran it, whether it succeeded and a short version of the output. The spreadsheet and tab are set once as an app setting.

Recording a new automation is the most important part, because it is how a non technical person creates one without writing anything. A Record new task button calls Create Demonstration, which returns a shareable link. Show that link prominently with a copy button, open it in a new tab, and explain that the person should now perform the task once by hand in that browser window. While it is open, poll Get Demonstration Status and show the current state so they know it is still recording. When they are done, a Finish and save button calls Complete Demonstration Recording, which compiles the recorded actions into a real task; keep polling until the compiled task id comes back, then show the new task in the library. A Discard button calls Stop Demonstration so a bad take is abandoned without creating anything.

Admins get a version drawer on each task. Opening it lists every version from List Task Versions (Legacy) with its version number, whether it is published, and when it was created. Selecting a version loads its full detail with Get Task Version (Legacy) so an admin can read what the automation actually does before trusting it, and a Publish button calls Publish Task Version (Legacy) to make that version the one everyone else runs. The drawer also has a Save as new version action that calls Deploy Task (Legacy) to cut a new auto incremented version, and a form for creating or editing a task definition with Create Task (Legacy).

Each task also has a run history tab listing past executions from List Task Executions (Legacy), newest first, with the run time, the result and the output. Where a run has a browser session behind it, look up its recording with List Session Recordings and Get Session Recording and link out to it, so when an automation fails somebody can watch the browser session back rather than reproducing the failure by hand.

There are two kinds of user. Admins see everything, including unpublished tasks, the version drawer and the recording controls. Everyone else sees only published tasks, the Run button, the results panel and the run history. Keep the admin list as a simple app setting. Keep the wording inside the app plain enough that someone can use it with no training, so tasks, runs, versions and recordings rather than anything that sounds technical.