Robotic Process Automation

01Purpose and scope

• This manual supports the course Robotic Process Automation. It describes how practitioners select, build, test, deploy, and maintain software robots that carry out rule-based tasks inside existing business applications. It is written as a working reference for analysts, developers, process owners, and operations staff who share responsibility for automation work.
• The scope covers attended and unattended bots that operate through user interfaces, along with the governance needed to keep them reliable. It does not cover machine learning models, full application redesign, or system integration through custom APIs, although RPA projects often meet those topics at their edges. Where a task requires judgment that a rule set cannot capture, the manual points to where a person or another system should take over.
• Context matters. A finance back office processing vendor invoices, a claims team at an insurer, and an IT service desk resetting accounts may use the same tools but face different data sensitivity, audit demands, and rates of change. Where a process touches regulated data such as health, tax, or payment information, this guidance does not replace qualified professional judgment, approved procedures, or authorization from the data owner and compliance function. Data handling rules depend on jurisdiction and sector, so confirm current requirements with the authoritative source in your location.

02Core principles

• Automate a process only after it is understood. A bot copies the steps it is given, so it also copies errors, exceptions, and workarounds unless someone removes them first. Map the process as people actually perform it, including the shortcuts, and not only as the written procedure describes it.
• Prefer stable, rule-based steps with clear inputs and outputs. Screens that change often, free text that needs interpretation, and decisions that depend on context are poor candidates for a rules-driven robot. Those cases usually need a different design, such as an exception queue handled by trained staff.
• Keep bots visible and accountable. Each robot should have a named owner, a documented purpose, controlled credentials, and logs that show what it did and when. A bot that nobody monitors is a liability rather than a saving.
• Design for failure. Applications time out, vendors push interface updates, and source data arrives malformed. A sound design detects these conditions, stops safely without writing partial results, and routes the work to a person with enough context to resolve it.

03Planning and preparation

• Start with a process assessment. Pick a process with high volume, clear rules, digital inputs, and a manageable number of exceptions. Record handling time, monthly or weekly volume, error rate, and the number of systems each case touches. Your own measured figures are far more useful for planning than numbers borrowed from vendor material.
• Build a business case that counts the real costs. License fees, development hours, infrastructure, support time, and the work to repair the robot after each application update all belong in the estimate. Many early projects underestimate maintenance, which often becomes the largest recurring expense.
• Secure access before development begins. Confirm that a service account can be created, that credentials can be stored in an approved vault, and that a test environment holds realistic but de-identified data. Request production access early, because approval timelines frequently delay projects more than the coding does.
• Choose tooling against your constraints rather than feature lists. Consider whether your organization already holds a license, the skills of the team, support for your target applications, and whether the platform offers version control, logging, and a central orchestrator. When possible, pilot two candidate platforms on the same process before committing.

04Recommended workflow

1. 1
   : Define the process boundary, the trigger that starts a case, the systems involved, and the output that counts as complete. Record this in a short process definition that the process owner signs off on before any build work starts.
2. 2
   : Document the as-is process by observing several complete cases, including the rare ones. Note where people consult email, spreadsheets, or a colleague for help, because those hidden steps are the most common cause of later breakage.
3. 3
   : Decide what to automate. Label each step as fully automatable, automatable with a human check, or retained by a person. Estimate the share of cases expected to flow through without exception and use that as the initial target.
4. 4
   : Design the bot. Specify input sources, how screen objects will be identified, decision rules, retry logic, and the exact exception categories. Prefer database access or application programming interfaces where they are available and approved, since they tend to be more stable than screen interaction.
5. 5
   : Build in small increments. Develop the normal path first, then add exception handling for each documented case. Keep credentials out of the code and place file paths, thresholds, and environment names in configuration parameters.
6. 6
   : Test in a controlled environment with representative data. Run the bot against a copy of the process for enough cycles to surface the common exceptions, then compare its outputs with staff results on the same cases.
7. 7
   : Deploy in stages. Begin with limited volume or a shadow mode in which the bot runs beside staff without committing results. Move to full operation only after the thresholds agreed in the design have been met for a defined period.
8. 8
   : Hand over to operations. Provide a runbook, monitoring dashboards, alert routing, and a written procedure for pausing the robot and rolling back its changes.

05Quality checks, risk controls and compliance

• Test at several levels. Unit tests cover reusable components, end-to-end runs cover realistic cases, and regression tests run after every change, including application updates. Screen-based tests are fragile, so focus them on the steps where a failure would be expensive.
• Control credentials and access. Bots should run under dedicated accounts with only the permissions the task requires. Rotate secrets through the approved vault and avoid sharing one account among several robots, because shared accounts make logs and audits hard to read.
• Preserve an audit trail. Log the transaction identifier, the decision taken, the timestamp, and the system changed, while keeping personal data out of logs where it is not needed. Reviewers often need to reconstruct what a bot did months later, so retention periods should be set with the records owner.
• Address segregation of duties. A robot that both creates and approves a payment, for example, can defeat a control designed for people. Involve internal audit or the control function early, before the design is fixed.
• Recognize the limits. Bots do not understand meaning and cannot accept responsibility for decisions. Where a process carries legal, financial, clinical, or safety consequences, qualified staff must approve the rules and exception handling, and the organization's own procedures and any required authorization govern the work.

06Collaboration and documentation

• Assign roles clearly. The process owner sets scope and accepts outcomes. The business analyst documents the process. The developer builds and maintains the robot. Infrastructure staff manage hosting and scheduling. Security reviews credentials and network access. Operations watches daily runs and clears the exception queue.
• Keep documentation current. Each robot should have a process definition, design document, test evidence, change log, and runbook. Store them in a shared repository with version history and link them to the robot's change ticket.
• Communicate with the people whose work will change. Staff who handled exceptions before automation may now own a smaller but harder queue. Explain what the bot will do, what it will not do, and how to report a problem. Early involvement exposes hidden steps and reduces resistance.
• Coordinate changes across systems. When an application owner announces an upgrade, the robot owner should schedule a regression run before the change reaches production. Keep a shared calendar of planned changes for every system a robot depends on.

07Measures and continuous improvement

• Track a small set of indicators: percentage of cases completed without human intervention, exception rate by category, time to resolve exceptions, run success rate, and cost per transaction. Compare these with the baseline recorded during assessment rather than with outside benchmarks, since process mixes differ widely.
• Review exception categories regularly, often monthly. Recurring exceptions usually point to an upstream data quality problem, a missing rule, or an application change. Fixing the source is generally cheaper than adding more handling inside the robot.
• Retire or redesign robots that no longer justify their upkeep. A process may change, a vendor may release a stable interface, or volume may fall. Set a review date for each robot and record the decision made at each review.
• Accept trade-offs openly. Higher automation rates usually mean more complex bots and heavier maintenance. Lower maintenance often means leaving more steps manual. Make that choice explicit with the process owner rather than letting it emerge from the build.

08Common mistakes and how to prevent them

• Automating a broken process. Speed amplifies errors. Fix the process, or at least document its known defects and the workarounds, before building anything.
• Relying on fragile selectors. Bots that depend on screen position or unstable labels fail after small interface changes. Use stable identifiers where the platform supports them, and run regression tests after each application update.
• Using personal or shared credentials. Running a robot under an employee's login creates audit problems and breaks when that person leaves or changes role. Use dedicated, vaulted service accounts from the start.
• Running without monitoring. Bots that fail silently can leave work undone for days. Configure alerts with a named recipient, and test that the alerts actually arrive.
• Ignoring maintenance cost. Budget for ongoing support at the start and include it in the business case, so that the first application update does not stall the program.

09Practical checklist

• Confirm the process owner has signed off on the process definition and scope.
• Measure baseline volume, handling time, error rate, and exception share from real data.
• Verify that a dedicated service account and vaulted credentials are approved before build starts.
• Document exception categories and the handling route for each one.
• Test on representative data and compare results with staff outputs on the same cases.
• Run a shadow or limited-volume deployment and agree the thresholds for full operation.
• Confirm logs capture the transaction identifier, decision, timestamp, and system changed.
• Check segregation of duties with the control function before go-live.
• Configure alerts with a named recipient and test them.
• Schedule regression tests for every planned application change and review the robot on a set date.

★Learning sources

• Micro Degree: Robotic Process Automation
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics