Automating a Weekly Inventory Workflow with Power Automate Desktop

Every week, part of my ticket-operations workflow involved the same manual routine: open the StubHub inventory site, apply the same filters, and work down a research spreadsheet of performers one by one — searching each name, adding what qualified, and noting the ones with no events. It's exactly the kind of task that is too UI-bound for an API integration but too repetitive to keep doing by hand. So I automated it with Power Automate Desktop, Microsoft's desktop RPA tool.

This post walks through how the flow works and the design decisions that made it reliable enough to run unattended, week after week.

What the flow does

The flow runs on a weekly cycle, and its first job is to know where it is in that cycle:

• Weekly reset. On start, it gets the current date and time in Pacific time and checks the day of week. If it's Sunday at 6:00 AM or later, the week is over: it resets the state file (CompletedSpecPerformerList.txt) and stops. Every other run continues the current week's work.
• Browser setup. It launches Chrome, navigates to the StubHub inventory page, and clicks through the same sequence of filters I would apply manually, so every run starts from an identical page state.
• Reading the work list. It opens the research workbook (Weekly Pulls Research - Auto Spec Version.xlsx), goes to the last worksheet, and reads the performer list from column D. Then it reads the completed-list file and subtracts every performer that's already been processed this week — so the run only ever works on what's left.
• Processing each performer. For each remaining name, the flow marks it as completed in the state file, types the name into the site's search field, and looks for the expected elements on the page. If the right buttons appear, it clicks them and writes an Added on [date/time] timestamp back into column C of the spreadsheet. If no events exist for that performer, it logs the name to NoEventsAvailable.txt and writes "No Events were found." into column B instead. Pop-ups that appear along the way are detected and closed so they never stall the loop.
• Cleanup. When the list is exhausted, it saves and closes the workbook and closes the browser.

Design decisions that mattered

• A plain text file as the resume point. UI automation fails in ways APIs don't — a page renders slowly, an element moves, the browser crashes. Instead of trying to make one run bulletproof, I made the flow restartable: the completed-list file records progress as it happens, and every run begins by subtracting it from the Excel list. If a run dies at performer 40 of 120, the next run picks up at 41. No database, no scheduler state — one text file.
• The spreadsheet is the audit trail. Rather than logging to a file nobody opens, results go back into the workbook the team already lives in: a timestamp in column C for every performer added, and an explicit "No Events were found." note in column B for the rest. Anyone can open the sheet and see exactly what the robot did and when, with zero training.
• "No result" is a result. Early on, the tempting shortcut is to only handle the happy path and let empty searches fall through silently. Recording no-event performers in their own log — and in the sheet — turned the flow from "it added some stuff" into a complete accounting of the whole list, which is what makes it trustworthy enough to replace the manual pass entirely.
• Human-paced interaction. The flow inserts randomized delays between actions instead of firing clicks as fast as the tool allows. Web pages need time to render after each interaction, and a fixed short delay is exactly the kind of thing that works in testing and fails at 2 AM when the site is slow. Variable, generous pacing made the flow far more stable.
• Expect pop-ups everywhere. Marketing overlays and dialogs are the classic RPA killer: the flow is waiting for a button that's now behind a modal. Checking for known pop-up elements at each step of the loop — and closing them when present — cost a few extra actions per iteration and eliminated a whole class of stuck runs.

Why Power Automate Desktop

Most of my automation work is code — .NET services, Azure Functions, scheduled jobs. For this task, RPA was honestly the better tool:

• The work happens in a web UI with no API for what I needed, driven by a spreadsheet a human maintains. That's PAD's home turf: browser automation and Excel actions are first-class building blocks.
• The flow is visual and self-documenting. When the site changes a button, fixing the flow means re-capturing one element, not redeploying anything.
• It runs on the same desktop the team works on, using the same logged-in browser session — no infrastructure to stand up for a once-a-week job.

The trade-off is fragility to UI change, which is exactly why the restartability and audit-trail decisions above matter more in RPA than in ordinary code. A flow you can re-run safely after any failure doesn't need to be perfect — it needs to be resumable.

---

More case studies on the Featured Projects page, or reach me at letanphp@gmail.com.