DocsDesktop process design considerations
This section covers some of the considerations that should be made when creating a solution for
Designing processes for Desktop is slightly different from an unattended RPA solution. With Desktop automations users are directly contributing to the running of a process, with the expectation that the automation runs consistently and successfully. In unattended RPA, workloads are processed in bulk and digital workers loop continuously, working case after case, operating in a clean, consistent, and unobserved environment. By contrast, in Desktop automations, cases tend to come one at a time, the state of the environment is less predictable, and the user is present to observe, participate, and potentially interfere.
It is important that care is taken to ensure that a Desktop solution is designed in a way that offers an optimal user experience, maximizes performance, and mitigates any risk of failure.
Solution design considerations
The following elements must be considered when designing an automation for Desktop.
User requirements
As with unattended RPA, identifying and agreeing requirements and success criteria are key to a successful project. With Desktop automation the Desktop user must also be considered.
Business analysts and solution designers should consider the users as customers, and ideally involve them in the requirements gathering, process walk-throughs, design workshops, and design sign-off. These users are the subject matter experts (SMEs) of the business process and will have a good understanding of the process and its associated workarounds, and problems. This valuable knowledge and experience should be utilized when designing an automation for Desktop.
Having user representation on the project will also help encourage user buy-in and ensure they are informed. Because the ultimate aim is for users to welcome and benefit from automation, their involvement will minimize the chance of low uptake or even rejection of a Desktop solution.
Solution shape
As already mentioned, unattended RPA solutions are meant to work one case after another, so usually utilize loops. Desktop solutions do not involve a work queue and will tend to work one case at a time, as directed by the Desktop user. This means that Desktop processes are more likely to be linear rather than circular in design as loops are not generally used. This isn’t to say that a Desktop process could not be designed to repeat certain steps, but by nature, requirements will veer more toward ‘one-shot’ automation rather than batch work.
Process structure
As with a standard
Preliminary checks
It’s very likely that a Desktop solution will need to make multiple initial checks when it starts to run. An unattended automation will operate in a virtual environment built specifically for runtime resources, the machine specification is known and the state of the machine is controllable and predictable.
The Desktop environment is far less clean and more uncertain. Specifications and builds may not be standard, the state of the machine cannot be presumed, and the actions of the user are unpredictable. In summary, a Desktop automation is able to make far fewer assumptions about the environment that it is operating in, and it will need to make more allowances than a Blue Prism Enterprise automation. The following are some of the additional checks that a Desktop automation may need to make:
- Did the user enter valid input parameters?
- What is the state of the target application – is it already running, is the user logged in, what screen is open in the application, or does the application need to be launched?
- Is the version of the target application as expected?
- Is screen resolution important and does the machine meet the requirements?
- Is the Windows version important and does the machine meet the requirements?
- Are the user’s credentials in the Windows credential store?
Some form of exception handling will be required to inform the user of the issue where the problem cannot be resolved by the automation.
Minimized applications
It is possible for a Desktop user to minimize an active application from the taskbar while an automation is running. It is therefore recommended that the process design includes checks that the target application is active and visible on screen where required.
Exception handling
For a Blue Prism Enterprise automation, exception handling can be as simple as recording the detail of the problem against the queue item and moving on to the next case. But in Desktop, there is no work queue and there probably is no next case, so the solution designer must make every effort to keep the user informed.
Mid-process terminations should be avoided and instead problems should be reported back to the user gracefully. The language used should be tailored to the user, who may not have technical experience.
The user’s actions may be the cause of the problem and the solution designer should attempt to anticipate user interaction. Training will go some way towards controlling user behavior, but the designer of a Desktop automation should expect the unexpected. There is no simple solution to this problem, but being aware of such factors will help when designing processes for Desktop.
