Unattended RPA — the real problem isn't starting the bot

Unattended RPA is not just about running a bot without a user

I was working on an unattended desktop automation recently, and one thing that stood out to me was that making the bot run automatically is actually the easier part.

The real question is:

What happens when nobody is there to fix it?

For example, the bot starts processing invoices at night.

The machine is available.
The user session is ready.
The desktop flow starts normally.

But halfway through the process, the legacy application shows a popup that wasn't there during development.

The bot stops.

There is no person sitting in front of the machine.

Now the problem is no longer just a failed desktop flow. The question becomes how the automation is going to recover.

This made me look at unattended RPA a little differently.

Before moving a desktop automation to production, I think we should consider things like:

• What if the machine is unavailable?
• What if someone is already logged in?
• What if the target application is down?
• What if the application UI changes?
• What if credentials expire?
• What if the bot fails after completing 50% of the transactions?
• How do we know which transactions were completed?
• Can the process be restarted without processing the same transaction twice?

For me, an unattended automation is not really unattended if someone from the support team has to keep checking it manually.

The automation needs a proper failure and recovery strategy as well.

The interesting part of RPA isn't making the happy path work. It's deciding what should happen when the happy path doesn't happen.

What has been your experience with unattended desktop flows in production?

#PowerAutomate #PowerAutomateDesktop #RPA #UnattendedRPA #PowerPlatform