Release Notes
Workforce Agent Core v8.0 & Service Helper v1.23
What's new
Workforce Agent Core v8.0.2 / Service Helper v1.23.0.
Changes to Workforce Agent Core
- Security improvement: the password used for desktop connections is now handled more securely.
- Updated dependencies.
Changes to Service Helper
- Updated FreeRDP to the latest version for improved desktop connection stability.
- Updated dependencies.
Worker v7.6.3
Updates:
-
When the "use desktop" option is enabled from Control Room, create a proxy executor only when the worker is running with "--service" CLI argument
-
By default a service created with Service Helper "setup-desktop" command will set the worker to run with this argument
-
Better error handling when fetching CA certificates from system store
You can find the detailed changelog for Workforce Agent Core here.
Worker 7.6.1
Updates:
- Upgrade RCC to v17.12.0
- Improve RDP connection error messages
- Close the FreeRDP client gracefully to make sure the full logs are received
- Ignore native-certs module load failure in Windows evaluation versions
- If the module is not loaded the support for loading CA certificates from system store is disabled
New experimental feature to use Windows Remote Desktop Connection Manager tool as the RDP connector with desktop setup. RDCMan is used automatically if config file is found from path: %LOCALAPPDATA%\robocorp\workforce-agent-core-service\rdcman-config.rdg. It can also be configured via the environment variable "RC_WORKER_RDCMAN_CONFIG_PATH", pointing to the RDCMan config file path.
You can find the detailed changelog for Workforce Agent Core here.
Worker v7.3.1
Updates:
- Worker network actions now use CA certificates automatically from the system certificate store (NodeJS support for firewall / proxy certificates)
- Upgrade RCC to v17.10.0
- Fix an issue where a slow environment resulted to a backlog of desktop stream files to be sent long after execution had finished
You can find the detailed changelog for Workforce Agent Core here.
Workforce Agent Core v7.1.6
- Upgrade RCC to v17.3.0:
- Supports layered environment building, unique conda-forge section build once, and cached
- Embedded micromamba and version update to v1.5.1
- Improvements to the process list after execution on Windows
- Profile support to allow Legacy SSL Renegotiation
- v17 major change: 'rcc interactive configuration' removed as Robocorp Setup Utility has the UI for creating profiles
Developer Tools September Updates 🏗️
As you may have noticed, we have been pushing out many updates to our tools and libraries lately, so a summary of the key things you can gain by updating is in place.
Support for newer type firewalls (MITM)
New firewall setups are coming to many companies, so we had to be the bridge to get the open-source frameworks to work inside these protected networks. Tools and libraries have been updated, and we have documentation here and here.
VS Code extensions
Support for our new Python logging is now built into VS Code, and several smaller improvements and supports for Python developers have been added.

There is a dependency helper that highlights and helps you update your dependencies to new versions. Just hover over the dependencies, and you will see the versions available.

The full changelog is worth following if you want to keep up with the updates.
Setup Utility, Worker, and RCC
The latest version of Setup Utility adds new checks to identify potential blockers for Windows RDP setups. It adds a lot of new information coming from RCC diagnostics for the firewall setups and testing.
For the Worker, we would like to draw your attention to Cloud Workers specifically. Many are still running their processes on the older Ubuntu containers, so a kind reminder to update to the new Cloud Workers.
We have not seen any problems arising from this change, but switching to the new one has fixed a few cases. We also have the latest Worker (v7.1.3) in the Cloud Worker (early access), so you can always test the next upcoming Cloud Worker by using that one.

Worker v7.1.3
NOTE: The major version upgrade was done due to the changes to the interface between the proxy and the executor. This should not require any actions from the user as both the service and executor uses the same executable when setup is done via Robocorp Service Helper or Robocorp Setup Utility.
Updates:
- Support RCC environmentConfigs setting when sending environment configuration file to the Control Room
- Fix issue where too large first artifact blocks sending the rest of the artifacts
- Run quick RCC diagnostics when starting worker
- Always send the console messages via the proxy connector instead directly from the executor
- Simplify the interface between proxy and the executor
- Make the console.txt a DEBUG level log
- Add local timezone offset to the ISO8601 time string in the log event messages detectedAt field
- Add better error message when user requests video streaming but worker configuration has video streaming disabled
- Use Node v18 (latest LTS) to build executable
- Upgrade RCC to v16.5.0
You can find the detailed changelog for Workforce Agent Core here.
Worker v6.34.7
Worker release v6.34.7.
Fixes an issue where extracted RCC executable was sometimes locked for the first API call.
You can find the detailed changelog for Workforce Agent Core here.
Worker v6.34.6
Worker release v6.34.6.
Minor update that improves logging and updates the RCC to latest version (14.15.4).
You can find the detailed changelog for Workforce Agent Core here.
Worker v6.34.4
Workforce Agent Core v6.34.4
- Add more information to the artifact upload end event
- Bundle RCC into the Worker executable and extract it during runtime
- Upgrade RCC to v14.15.3
You can find the detailed changelog for Workforce Agent Core here.
Updated Worker Views and More
In this Control Room update, we are introducing brand new and improved Worker views for you to conveniently manage a large number of Workers, along with a few smaller UX improvements and bug fixes.
Improved Worker Views
.png)
The Worker views have been updated to enable more convenient management of Workers and troubleshooting of potential issues in your unattended automations, especially in cases where there are multiple self-hosted Workers or groups involved.
The new views have been structured to provide more information about how the Worker is used in different Processes, Steps, and Groups, in addition to sorting and filtering of data, which helps you to stay on top of operations. Also, the user experience of linking new Workers and managing groups has been improved.
Other improvements and bugfixes
- The parallel execution limit in steps is no more limited by the Worker group size
- Autoremove option has been added to the group link tokens, enabling better management of temporary execution environments
- The rare case of scheduler double triggering process runs has been fixed
- UX improvements to the Vault UI
- The bug where VSCode was unable to get secrets when "Prevent viewing Vault secret values" was enabled has been fixed
As always, we in Robocorp would be most interested to hear what you think about the update, so don't hesitate to contact us in the community Slack!
Worker v6.32.3
- Adds the ability to the Worker to check for the
rccexecutable in the Workers Common Path - If
rccexecutable isn't found in either path (the instance path & the Workers Common Path), it will download it as it did before - This will provide a more reliable determination in use cases involving
Setup Utility
Have a good day!
🎉 Robocorp Setup Utility v0.15.0
-
Service Helper v1.11.2is recommended -
Go to
Internal Statuspage and upgradeService Helper -
Latest
Service Helpersets the correct permissions for log on service, you don't need the last steps inSetup Utilityanymore when adding a new Windows Worker-
Checking if the user already has a worker designated to it - one worker per user; if the user has already a worker, a new worker is rejected
-
Enable/Disable video stream/data transfer is now possible directly from
Setup Utility -
Test the RDP Connection by opening one directly from
Setup Utility -
Adding a new Windows Worker is prefaced by an automatic profile deployment to the user - the current profile from the Admin account is used for the deployment - as such, the proper
rccenvironment is propagated to all users -
Manually deploy the current profile to a desired user account from
Profile Management -
Reinforced clean up after Worker is removed - deleting known files from known locations
-
-
Fixed the
Submit Issueproblems -
You can now reliably Submit Issues to us and we thank you for them :)
-
Improvements in the UI/UX in certain areas of the app
Have a splendid day! 🎉
Worker v6.32.2
Workforce Agent Core v6.32.2
- Fixes an issue where worker executor was left running after the connection to Control Room was already lost
- Fixes an issue where keyboard interrupt or SIGINT would exit the application with exit code zero
You can find the detailed changelog for Workforce Agent Core here.
Robocorp Setup Utility v0.13.3
Added System Toolbox to fix the most common system-level settings
Detection if the user is an administrator and hides features that cannot be used.
Submit Issue is now available:
-
Submit Issue creates the report as Generate Report & sends that as attachment
-
The report package will still be available for the user locally
Fixes to the Windows Desktop Worker setup:
-
Fixed issues with User & Domain
-
Added ability to test user credentials
Download Robocorp Setup Utility from our download site.
Worker v6.32.0
Workforce Agent Core v6.32.0
Fixes an issue with desktop setup when "Do not signout after run" option was used. The agent core was left running even after the execution.
You can find the detailed changelog for Workforce Agent Core here.
Second generation of Robocorp-hosted Cloud Workers
CLOUD WORKERS - ACTION REQUIRED
We are announcing three significant changes to the Robocorp-hosted Cloud Workers:
-
Modernization of the Linux distribution from Ubuntu 18.04 to Debian 12.0 "bookworm".
-
Predictable performance via specified resource quotas.
-
Update process that enables testing upcoming container versions beforehand and reverting to a previous version in case of problems.
These changes do not affect any previously deployed robots (yet), but we recommend migrating to the new Debian-based container to stay up to date with security updates.
If no action is taken, step configurations will be migrated automatically starting January 1, 2024.
OK, WHAT SHOULD I DO?
👉 Update your step configurations to use "Cloud Worker" instead of "Cloud Worker (Ubuntu 18.04 legacy)"
👉 Test that the robot still runs as expected.
We expect the overwhelming majority of robots to just work without any modifications.
BACKGROUND & DETAILS
Since their launch in 2019, the Robocorp-hosted Cloud Workers have been powered by Ubuntu 18.04 as the underlying distribution. It has proven to be a stable foundation for many popular use cases such as Browser and API automation. However, as of June 2023, Ubuntu 18.04 has reached the end of the standard maintenance window and it is time to move on. Unfortunately starting with Ubuntu 20.04, Chromium is distributed as a Snap package, which does not play nice with containers. Therefore we decided to upgrade to Debian instead.
Unpredictable performance was a common pain point with the first generation of Robocorp-hosted containers. The containers were historically run with a relatively small amount of guaranteed resources (1/4 vCPU, 256 MB RAM, 20 GB disk), but any excess capacity on the underlying cluster was made available to the containers. This resulted in great performance most of the time, but in the case of load spikes, the performance could drop significantly. The Debian-based containers are run with hard resource quotas of 1 vCPU, 3.5 GB RAM and 20 GB disk. In practical terms, the performance is always the same, regardless of total resource utilization.
Finally, we used to have just one version of the Cloud Worker available. It was not possible to 1) test upcoming versions in advance or 2) selectively revert back to a previous version in case of issues. For the 2nd generation of Cloud Workers we are offering three variants. The "early access" version is the bleeding edge, which can change anytime. Once deemed stable, some versions will be selectively promoted to the default version after a 2-week notice period. Customers interested in ensuring maximum stability have two weeks to test the upcoming release. Finally, the "previous" version points to the version that was previously the default, meaning it is possible to effectively roll back in case something breaks.
To summarize, the following changes are live as of today:
-
The Ubuntu-based Cloud Worker has been renamed as "Cloud Worker (Ubuntu 18.04 legacy)" to indicate the EOL status.
-
Three new Cloud Worker options have been added. See the docs page for a description: https://robocorp.com/docs/control-room/unattended/worker-setups/robocorp-container#different-cloud-worker-versions
-
New steps are assigned to the Debian-based, current container version by default.
-
The legacy Ubuntu-based container continues to run with a soft resource quota. The new Debian container runs with a (significantly increased) hard quota.
KNOWN ISSUES
Currently, if a step run gets terminated due to exceeding the memory or disk quota, the run fails with a "Connection loss" error. We are working on adding better error reporting.
Setup Utility: Managing your Desktop Workers just got easier 🎉
👉 You can now manage your Windows Workers just by logging in as the server's admin and using Setup Utility.
Setup Utility lets you see which ones are busy, CPU loads, versions, jump to the correct Worker in Control Room, etc. Setup Utility also now handles the permission setting so that you can directly create Workers on user accounts without admin permissions.

The service-helper CLI tool is still there, and Setup Utility is using it, so the CLI support needed by IT departments using fleet management systems is going nowhere.
👉 The update path is to update your existing Workers to v6.31.1 using the service-helper so that Setup Utility can see them. After that, you can do everything in Setup Utility.
You can find the documentation on Setup Utility in our docs
There is also support for Demo Worker, which is designed to replace the Robocorp Workforce Agent UI application. So if you need to demonstrate robot runs on your machine, this is the place for you.
This was one of the “this should be simple” features that turned out to be a bit bigger thing 😉, so big props to Kosmo & Matti from my team!
I'd also want to thank a few enterprise customers and their IT departments, but I do not know if I can ping their names, so I'll just give an anonymous thank you here. 🙏
Worker v6.31.1
Workforce Agent Core v6.31.1
Changes to the Workforce Agent Core:
-
Cleanup temporary video files once they have been processed to save diskspace
-
Fixed video streaming issues
-
Fix an issue where on terminate command failure the desktop video streamer would keep running when worker is in error state
-
Fix logging issue with video streamer when delete file event is handled
-
Added a status files for agent-core instances to common location for Robocorp Setup Utility tool
-
Status file for agent containing all relevant information from device and Control Room
-
Added the
statuscommand that reads from the Status file and prints information to the user -
Added new handlers for exit situations
-
A new way to handle a graceful shutdown with listeners for standard I/O
-
Update dependencies
You can find the detailed changelog for Workforce Agent Core here.
Pre-build robot environments 🏗️
👉 Need to control or scan every file your automations use in production?
👉 Want to save time / protect developers from environment building?
We now have a solution for setting up environment pre-building inside your company network so that all robot runs and developer tools can get environments much faster.
The setup enables you to build the environments on dedicated machines and, if needed, scan the results before passing them on to your users.
The client machines only download missing files to get the environment which means drastic speed improvements over time as the environments share many of the same files.

🚀 The documentation covers the feature and setup, but if there are any questions, do not hesitate to ping us.