RPA Bot Maintenance and Updates
A deployed bot is not permanent. Business processes evolve. Applications get updated. Websites redesign their layouts. Regulations change. Any of these events can break a working bot. Regular maintenance keeps bots healthy, reliable, and aligned with current business reality. Organisations that plan for maintenance from the start experience far fewer production crises.
Common Causes of Bot Failure After Deployment
| Cause | Example | Impact |
|---|---|---|
| Application UI change | SAP updated; button ID changed | Selector fails — bot stops |
| Website redesign | Supplier portal navigation restructured | Web scraping breaks |
| Business rule change | Approval threshold raised from $5,000 to $10,000 | Wrong transactions sent for approval |
| Data format change | Date format changed from DD/MM/YYYY to MM-DD-YYYY | Date parsing fails — bot errors |
| New exception type | New invoice category added that bot was not built for | Bot handles it incorrectly |
| Platform version upgrade | UiPath upgraded to new version — activity API changed | Workflow compilation fails |
| Credential expiry | SAP password expired — bot cannot log in | All runs fail until password updated |
| Volume spike | Month-end processing quadruples transaction count | Bot queue backs up; SLA missed |
The Maintenance Lifecycle
┌──────────────────────────────────────────────────────┐ │ BOT MAINTENANCE CYCLE │ │ │ │ MONITOR DETECT ANALYSE │ │ (Daily ops) ──▶ (Alert fired) ──▶ (Root cause) │ │ ▲ │ │ │ │ ▼ │ │ VALIDATE ◀── DEPLOY ◀── FIX / UPDATE │ │ (Test fix) (Prod release) (Dev + test) │ └──────────────────────────────────────────────────────┘
Types of Bot Maintenance
Corrective Maintenance
Fixing a bot that has broken. This is reactive — the bot fails, an alert fires, and the developer investigates and repairs.
Examples: Updating a broken selector, fixing a data parsing error, resolving a login failure caused by a password change.
Adaptive Maintenance
Updating the bot to accommodate changes in the business environment — new application versions, new business rules, new data formats. This is proactive when you know a change is coming, or reactive when a change happens unexpectedly.
Examples: Updating web scraping logic after a portal redesign, adding a new exception type after a process change.
Perfective Maintenance
Improving the bot without fixing a bug or responding to external change. You make the bot faster, more reliable, or easier to maintain based on operational experience.
Examples: Replacing an image-based selector with a more stable ID-based selector, refactoring a complex workflow into smaller reusable components, improving error messages for faster diagnosis.
Preventive Maintenance
Scheduled maintenance actions that prevent failures before they happen.
Examples: Refreshing API tokens before expiry, verifying selector health after an application patch, testing bots after a platform upgrade in a lower environment before it reaches production.
Selector Maintenance: The Most Common Task
Broken selectors are the leading cause of bot failures after deployment. When an application is updated, element IDs, class names, or page titles may change — invalidating existing selectors.
Selector Health Check Process
WHEN: After every application update in the target system
STEP 1: In UiPath Studio, open the bot project
STEP 2: Run the bot against the dev environment
STEP 3: Monitor for SelectorNotFoundException errors
STEP 4: For each broken selector:
→ Open Selector Editor
→ Click "Indicate on Screen" to re-capture the element
→ Compare new selector with old one to understand what changed
→ Update selector to stable properties (prefer ID over position)
STEP 5: Re-run full regression test
STEP 6: Deploy updated package to production
Managing Configuration Changes
Business rule changes — like approval thresholds, email addresses, or file paths — should never require a developer to open the workflow. Store all configurable values in Orchestrator Assets. When a rule changes, an administrator updates the Asset value and the bot automatically picks up the new value on its next run.
WRONG APPROACH (hardcoded):
IF invoiceAmount > 5000 THEN send for approval
→ Developer must change code, test, redeploy for every threshold change
RIGHT APPROACH (Orchestrator Asset):
approvalThreshold = GetAsset("ApprovalThreshold")
IF invoiceAmount > approvalThreshold THEN send for approval
→ Administrator changes Asset value in Orchestrator → done
→ No developer, no code change, no redeployment needed
Planned Maintenance Windows
For major updates, schedule a maintenance window — a period when the bot is temporarily stopped for updates. Communicate the window in advance to the business team so they can plan manual workarounds if needed.
- Notify stakeholders at least 48 hours in advance
- Schedule maintenance during low-volume periods (weekends, overnight)
- Stop the bot gracefully — allow the current transaction to complete before halting
- Test thoroughly in the UAT environment before the maintenance window
- Have a rollback plan ready in case the update introduces new issues
RPA Platform Version Upgrades
When the RPA platform itself (UiPath, AA, Blue Prism) releases a new major version, upgrade carefully:
- Read the release notes — check for breaking changes in activities or APIs
- Upgrade dev environment first and test all bots
- Fix any compatibility issues before upgrading UAT
- Only upgrade production after successful UAT validation
- Never upgrade all environments simultaneously
Bot Health Scorecard
Track the health of each deployed bot monthly:
| Bot Name | Success Rate | Last Failure | Open Issues | Last Updated | Health |
|---|---|---|---|---|---|
| InvoiceBot | 97.3% | 5 days ago | 0 | 2 weeks ago | Green |
| PayrollBot | 88.1% | Yesterday | 2 | 3 months ago | Amber |
| OnboardingBot | 72.0% | Today | 5 | 8 months ago | Red |
Red bots require immediate attention. Amber bots need scheduled maintenance. Green bots need only routine monitoring.
Estimating Maintenance Effort
As a rule of thumb, plan for 15–20% of the original development effort per year for ongoing maintenance. A bot that took 20 days to build typically requires 3–4 days of maintenance per year under stable conditions. Bots connected to frequently changing applications require more.
Summary
Bot maintenance is an ongoing responsibility that begins the moment a bot goes live. Corrective maintenance fixes broken bots. Adaptive maintenance keeps bots aligned with changing applications and business rules. Perfective maintenance improves reliability and performance. Preventive maintenance avoids failures before they happen. Store configurable values in Orchestrator Assets to avoid code changes for every business rule update. Maintain a bot health scorecard to prioritise which bots need attention. Budget 15–20% of development effort per year for maintenance — it is an unavoidable cost of keeping a live automation portfolio healthy.