Skip to Content

The robot user-ID: handling RPA within existing rights & permissions structures

Capgemini
2019-08-14

This blog article is part of our RPA blog series and deals with the important question of how to deal with robot user-IDs. Existing processes for the assignment of permissions within companies are developed for human beings and not for robots. This article shows, how existing processes can be adjusted to create individual robot user-IDs by answering the following questions:

  1. What is a robot user-ID?
  2. Why to create a robot user-ID?
  3. How to create a robot user-ID?

1. What is a robot user-ID?

If a new employee joins the company, automated back-office processes normally create a new user-ID and enrich it with the required rights and permissions for this employee. Based on the job profile the employee gets rights and permissions to various applications and platforms. Even if the rights are not granted upfront, the employee can request special rights and permissions individually.

How does it look like when setting up a new robot? Does a robot get the identical right set as a human employee, more rights, or less? Does it appear in the corporate directory? This question cannot be answered in general. However, it is crucial that the robot is able to access the existing software landscape like ERP-systems or mailing programs – with a non-technical user, able to access the user interface. Each robot needs an individual set of rights and permissions to execute these applications. For example, an employee in the HR department has a different set of access rights than an employee in the accounting department. Of course required access rights may differ with time. An easy option may be to grant a larger right set, but similar as for human employees you don’t want to have this for compliance and security aspects. The same differentiation ought to be made for each robot. We call this set of individual and general rights in combination with the user ID the robot user-ID.

2. Why to create a robot user-ID?

To separate between humans’ and robots’ work, a unique robot-ID is mandatory. This ID should include a master ID, log in credentials for applications and if required, a unique email address. By using this individual number for each robot, compliance and security aspects can be safeguarded. Next to that, the robot can be monitored, and statistical analysis can be operated. By logging the robots’ actions, in combination with a specific robot user-ID, the audit capabilities are always ensured. Besides this technical aspects the topic comes with a strong change impact: Do your robots have names or just identifiers? This is very much related to the question of whether you position the robot as virtual co-worker – treating it similar as human resources in many ways – or technical script – positioning it as pure automation driver. This topic will be dealt with in a separate blog article, focus here is on the user-ID as such.

3. How to create a robot user-ID?

The process of creating a robot user-ID should follow the default process of creating an ID for a human user to easily integrate it into your existing compliance and security concept. Hence, it is not required to create new processes specifically for RPA from scratch and extra work effort for the implementation of RPA is limited to minor modifications of the existing process.

The process of creating a robot user-ID consists normally of two steps:

  1. Creation of the technical robot-ID
    The technical set up of a robot user-ID should follow the default process of setting up a human user. Normally the “robot lead” (the owner of the robot) demands the setup of a new robot user-ID. This ID should be created in a special employee group within the ERP system to safeguard that the robot ID is not mixed up with human IDs. It is important to separate these because of statistical and payroll purposes – you don’t want the robot to get a wage wired to a certain bank account.
    The ERP system is commonly connected to the Group Directory, which controls the access to applications within the company. Within this system, a protected branch should be created and used for robots. This ensures that just applications, which are on a positive list, interact with the robot user-ID and that the range of applications is restricted and can be controlled.
  1. Provisioning of the roles and permissions
    Following the technical setup of the robot identity, robot specific roles and permissions have to be created. By using the existing methods of requesting and approving roles and rights for a robot, compliance aspects are ensured at every stage of the process.The “robot lead” is responsible for assigning application rights, roles, and permissions to the robot. These rights and permissions cover the required scope of the individual robot related processes. Thus, the rights must be determined per process to increase the robot utilization and guarantee compliance requirements. It is recommendable to follow the minimum set of rights approach and not determining admin rights to the robot – treating it as a standard employee will provoke least compliance issues. In most tools, one license can handle different user-IDs and instances. Using multiple IDs will help you utilizing licenses while not touching internal controls.Since a robot is not a human employee, it does not need the identical rights. Therefore, robots will not be considered by procedures that are only relevant for humans (headcount, salary, access card to cantina …). The following overview gives an indication, which general attributes are required by a robot and which are not required.

Key Take-Aways regarding the rights and permissions structures for a robot user-ID:

  • Process of robot user-ID creation should follow existing processes
  • The separation between human IDs and robot-IDs is recommended
  • Grant an individual set of rights to the robot

Find out more about this topic:

Author detailsNA Contact details
Stefan Burghardt
stefan.burghardt@capgemini.com		Wolfgang Enders
wolfgang.enders@capgemini.com