About Microbots - Hyland RPA - Foundation 23.2 - Foundation 23.2 - Ready - Hyland RPA - external

Hyland RPA

Hyland RPA
Hyland RPA
Foundation 23.2

Microbots have two basic uses - process-specific and generic. While process-specific Microbots represent a sub-process that only occurs in a specific process, the focus of generic Microbots is on reuse in loops, later in the same process or even in other processes.


Process-specific Microbots should reflect the building blocks in the process diagram and, if available, include generic Microbots to take advantage of reusability.


Generic Microbots have the goal of being reused in another process.

The Microbot should always perform only one specific task, for example, filling out an input mask or creating a ticket. As in classical programming, the size of Microbots should be as small as possible and as large as necessary. The more complex a Microbot becomes, the more error-prone and specific it becomes.

At the beginning of each Microbot, there should be a check of the passing arguments. If there are no mandatory variables, start the check at the beginning. Optional variables should only be used if they are valid and present. In other words, optional arguments can be omitted and necessary ones forced.

It is also essential that the corresponding steps within the Microbot are commented sufficiently to simplify their use. The more structured the Microbot is developed, the less comments are necessary. Generic Microbots should not call any more Microbots to prevent nesting.


  • Provide good and detailed comments for other users
  • No further scopes (microbots)

Naming Convention

Basically, the name of a Microbot must reflect its function. The name of the interface used by the Microbot must also be added. Since Microbots are generally to be kept short, their functionality is also limited, so that a useful name can be found.


  • [Interface] [Functionality]
  • Example: SapLogin, MCisCreateRequestTicket, WbciReadJobTable

Arguments in Microbots

To be able to recognize arguments more quickly, a prefix is added to the variable name. For incoming arguments In, for outgoing arguments Out and for arguments which work in both directions InOut. In this way, you can immediately see in the script whether it is an argument and whether it is an input or output argument.


  • Clear naming conventions of arguments
  • If-switch-branches for individual usage (if an argument is empty, check it and ignore it if it is empty)
  • In before input argument - InText
  • Out before output argument - OutCount
  • InOut before input/output argument - InOutList


RPA Designer provides the functionality to store Microbots in a central file location. This allows different projects to benefit from the same Microbots. In order to keep the repository clear, a folder structure is required. Each interface receives a folder in which the corresponding Microbots are stored. In addition to the interface folders, a helper folder can also be created to store system processes or procedures that do not use an interface.


  • For Application Microbots - ..\ApplicationName\Microbot (\SAP\SapLogin)
  • For Helper Microbots - ..\Helper\Microbot (Helper\DateTimeHelper

Microbots once stored in the repository may only be modified by the creator. If the Microbot has been transferred from the repository to an RPA Designer project and subsequently adapted, it must be renamed. It is now no longer allowed to commit to prevent a change of the origin Microbot. As long as no technical solution has been implemented, extreme caution must be exercised to prevent overwriting.