@marstamm Let me know if you would like to hop on a call and discuss, or if you are able to provide answers for any of the above. I am happy to launch a PR with these additions.

@christinaausley thank you for your support on these. I'll provide some rough content from the top of my head, we can have a quick call next week to discuss the details.

Setup and Deployment: Clear guidance on how to configure and deploy an RPA worker in a production environment would be very helpful. Currently, it’s not entirely clear how to properly transition from a development setup to a scalable, production-ready installation.

To Transition from a development setup to a production setup, there are a few things to consider:

• Disable the local sandbox: If your worker should only accept scripts from zeebe and not used for testing scripts from the modeler, disable the local execution by setting camunda.rpa.sandbox.enabled to false

• Does your Scripts require 3rd party tools? Install them along with the RPA worker so they are accessible from the scripts.

• Add Tags to your Worker and scripts: Depending on your use-case, it might be useful to tag your workers with their capabilities. Common ways for tagging include operation systems and available applications. Read more on tags <INSERT LINK TO TAG SECTION HERE>

Operating System Considerations: When is it possible to run the RPA worker on a headless Linux machine, and when is a Windows environment necessary? Please include examples or clear distinctions between these scenarios.

The RPA worker is available on all major Platforms (Windows, Linux and Mac). This allows you to automate your applications on their native platforms.

In most cases, this will be windows. For console applications or browser automation, you can use a more light-weight distribution, such as the Docker image.

Task Distribution (Labels): More details on how “labels” actually govern distribution of work would be beneficial. If a specific worker should only run a specific script, how do we ensure this is configured correctly?

Labels are set both on the RPA task in the diagram and on your worker. To ensure your script is only executed by machines with the correct capabilities for this script, it is highly recommended to add labels to your worker.

A worker can have multiple labels and will pick up any script that matches one of the given tags. E.g., your worker might have access to the SAP application, but you also want it to pick up browser automation tasks. In this case, add SAP,BROWSER_AUTOMATION to your workers tags. This will pick up tasks tages as SAP as well as tasks tagged as BROWSER_AUTOMATION.

If not Label is defined, both task and worker will use the label default.

Labels describe capabilities. If you want your worker to only pick up a specific script, you will need to use a unique label on both the worker and the RPA task.

Scaling the Bot Farm: Guidance on how to scale a bot farm effectively, including any best practices, would be valuable. For instance, how to manage concurrency, resource allocation, or fault tolerance as the bot farm grows.

(I am not that knowledgeable on the Dev-Ops side of things, we might link to this? https://docs.camunda.io/docs/components/best-practices/development/writing-good-workers/#organizing-glue-code-and-workers-in-process-solutions )

By default, workers will only request and execute 1 Job at a time. This ensures that there are no side effects from multiple scripts interacting with the system at a time.
By extension, that means that 1 machine should only host a single rpa-worker instance at a time. To allow execution of multiple scripts on a single machine, labels and concurrency should be used.

Some workloads do not require exclusivity of the worker. E.g., browser automation is usually side-effect free and can execute multiple Jobs in parallel.
In these cases, it can make sense to label your tasks that can be parallelized (e.g. BROWSER_AUTOMATION). Create separate workers with the corresponding label and camunda.rpa.zeebe.max-concurrent-jobs bigger than 1.

Error Handling and Recovery: What happens if a bot encounters an issue during execution and then picks up a new task? It would be helpful to include steps on ensuring the environment is reset—closing applications or other post-run cleanup—before the bot starts a new script.

If your rpa script runs into an unexpected error during execution, this error alongside the output will be reported to zeebe. If the Job retries are exceeded, an Incident will be created in Operate.

To ensure your Environment is always cleaned up and all open Applications closed, create a cleanup step and tag it as [Teardown]. Read more about Setup and Teardown in the RobotFramework documentation.

*** Settings ***
Library             Camunda
Library             Camunda.Browser.Selenium

*** Tasks ***
Main
    Perform Work
    [Teardown]    Cleanup

*** Keywords ***
Perform Work
    Open Browser      about:blank
    Fail

Cleanup
    # Close your application, even when encountering errors
    Close All Browsers

(We do not support creating BPMN errors right now, but will potentially do so until the 8.7 release. This will be handled as a keyword, but should be a separate PR)

File Distribution: A description of how files are shared or accessed by different bots would be useful. Who manages the distribution of assets or scripts, and how is version control handled?

Shared script resources are a potential topic for 8.8. Right now, the scripts can not reference other resources outside of what is defined in the scripts themselves.

Sample Architecture Diagram: An illustrative architecture diagram showing how the RPA workers integrate with the rest of the system would provide clarity on infrastructure layout and best practices.

TODO. If we have an existing diagram for service task workers, we could reuse it.

Quick response @marstamm! I will document this next week -- if what I have PRed does not make sense, we can schedule a call to sync.