The purpose of this article is to describe the reasons why customers should inform Basware before implementing RPA tasks and to provide best practice advice on RPA implementation.

Summary:

Many customers are implementing RPA use cases to automate daily routines. RPA as a concept is well suitable for many cases, however there are some things which need to be considered when implementing these cases. 

Instructions:

1. Basware production team has a need to follow the RPA usage and Basware product management has a need to understand the RPA usage to better support RPA use cases. There are also some cases where Basware cannot allow RPA usage as those would cause excessive usage of system resources. For these reasons a Configuration Exception should be filed for each RPA use case.
   
   
2. Customer implements RPA tasks.
   
   
3. Best practice advice.

• • Basware has DDOS prevention mechanisms in use. If a robot malfunctions really badly and causes excessive loads, automatic DDOS prevention could classify that as a DDOS attack and might block the IP address(es). So, customer should be careful not to create a robot task that could get classified as DDOS attack and could get their IP address(es) blocked. Things to avoid include high number of requests within short time from one or several IP addresses (i.e. don't setup the robot to fire too frequently, make it act on the pace of a human user).
    
  • Avoid automating unnecessary use cases. For example Basware monitors service availability in many ways and provides information about the availability, so it should be unnecessary to create service availability monitoring RPA by customers.
    
    
  • Always consider using APIs instead of UI access if possible. UI will change every now and then and that may result in the need to re-implement the RPA actions. UI is also optimized for human usage and can be less efficient when fetching a lot of data. Basware API provides REST APIs for many purposes and these APIs are stable backwards compatible APIs that don't break in release upgrades. Large scale data extracts should not be done with RPA via UI actions.
    
    
  • Each robot should have it's own account in Basware. There are two reasons for this. 1) With use case specific accounts the permissions can be defined following least privilege principle which increases customer security. Set the permissions so that the robot can do only what it is expected to do. 2) If a customer made robot malfunctions and causes excessive loads to Basware systems, but does not get blocked by Basware DDOS defence, Basware may be forced to disable the user. At that point it is of course better for the customer if that affects only to the use case that malfunctions and not to other RPA use cases that the customer has.
    
    
  • Robot usage should be developed using a DEV or a TEST tenant and deployed to production only once fully tested. This ensures that customer production data is kept safe from a malfunctioning robot, but also that production system resources are not compromised by a malfunctioning robot. Even when the robot in DEV or TEST seems to be working fine, let it run for some time in that tenant before deploying it to production. This extra time ensures that Basware has time to react if monitoring shows any issues.
    
    
  • If the robot is a scheduled action, the frequency should be carefully considered. For example the data in Analytics is changing once per day, so if the robot is a scheduled action, there should not be any reason to run the robot more frequently. Very high execution frequency could lead to a situation where the robot user causes excessive loads to Basware systems.
    
    
  • SSO is always the preferred method for authentication. Without SSO, the password will expire and needs to be changed every now and then. This password change can be avoided if Basware Access is used for authentication as Access don't have frequently expiring passwords. It is fair practice to name the robot users as "robot.usecase@customer.com" or in a similar easily identifiable way.