When a SaaS Rebrand Silently Broke Our Automation — Lessons from the freee→Pasture Migration

Our month-end automation pipeline fired at 5 PM. 4 of 6 tasks succeeded. 2 failed. The culprit: freee Business Outsourcing had rebranded to Pasture, taking the login URL and every form selector with it.

What Happened

Our team automates month-end timekeeping and invoicing tasks with a multi-agent system. One of those tasks handles time entry into Pasture (formerly freee Business Outsourcing).

When the 5 PM job ran, two Pasture-related tasks timed out. The logs showed them stuck on the login page.

# Before (broke)
URL: /login
selector: input[name="session[email]"]

# After (post-rebrand)
URL: /users/sign_in  
selector: input[name="user[email]"]

The rebrand came with a full frontend refresh. The login URL changed, form field names shifted from session[*] to user[*], and even the save button's value changed from "保存" to "更新".

The Fix Was Easy. The Discovery Was Late.

Fixing it took about 10 minutes — three string replacements per script. The real problem is when you find out.

These scripts only run at month-end, so there's no way to discover the breakage ahead of time without proactive testing. We did receive the rebranding announcement email, but while it said "the URL is changing," nobody told us "the form name attributes are changing too."

A Second Trap: Skipping State Verification

After patching one script and spending 30 minutes debugging, I happened to check the task status on Pasture — and found it had already been submitted manually at 8:44 AM that morning.

So the error might not have been "can't log in after rebrand" at all. It might have been "trying to modify an already-submitted task." If I'd checked "is the task actually pending?" first, I could have skipped all that debugging.

Lesson: Verify preconditions before jumping into error fixing.

What We're Putting in Place

Three changes we're implementing before next month's run:

1. Health check dry-run — Before the month-end live run, verify the login URL returns 200 and the selectors exist. Already integrated into a weekly dry-run job.
2. Pre-run state check — Confirm the target task is in "not submitted" state before the script proceeds.
3. Externalize selectors — Pull URLs and selectors out of the script and into a config file. Changes become diffs instead of hunts through code.

Takeaway

SaaS automation is powerful but fragile by nature — you're at the mercy of the vendor's frontend decisions. If a public API exists, use it. But for tools like Pasture where UI scraping is the only option, design for breakage from the start.

Weekly dry-runs, externalized selectors, pre-run state verification. Unglamorous, but these three things will cut most month-end incidents significantly.

---

Tags: SaaS automation Playwright month-end tasks multi-agent design for failure Pasture