Third-party portals change. Labels move. Buttons vanish. A flow that worked on Monday fails on Tuesday with no changelog for you. If your product only works on the happy path, that Tuesday is not an ops anecdote. It is a product verdict. I learned this building automation against social-security and hiring portals in Colombia — the same floor that later shaped ECORPA. This is not a how-to for affiliations. It is what the product must absorb when someone else owns the screen.

The Tuesday the screen changed

You do not need the entity name. You need the scene: a routine path the team ran every day, a selector that moved, a confirmation that stopped appearing, and a queue of people waiting while someone re-learned the portal by hand. The first instinct is to call it drama. It is not drama. It is the environment. Your job is to decide what breaks in public, what fails closed, and what you never promised in the first place.

Three reactions that feel good and age badly

Patch fast and forget. You restore the demo. You do not restore trust. The next change hits the same soft spot. Pretend nothing happened. Marketing keeps saying "set and forget." Operators know better. That gap becomes your brand. Redraw the contract. You treat the portal as an unstable dependency. You isolate adapters, make failure visible, and stop selling permanence you do not control. Only the third reaction compounds.

What the product should absorb vs what the operator should absorb

The product should absorb: locating the right step again, translating a known intent into the current UI or API shape, and failing with a clear reason when it cannot. The operator should absorb: judgment calls the system cannot own — exceptions, edge documents, human sign-off. If you automate judgment to look smart in a demo, you create silent wrong answers. Wrong answers are worse than visible stops.

Blast radius

One broken integration must not take down the whole workflow. If a single portal change freezes affiliations, checks, and document validation together, you did not build a system. You built a single point of fragility with a nice UI. Ship decision I still use: we do not ship a "fully automatic" path for a step whose external dependency changes without notice unless failure is loud, scoped, and recoverable without rewriting the rest of the product. That rule killed features that looked great in a deck. It belongs with the 99% in the drawer.

Health signal after a change

The useful metric is not "did we patch." It is: how long until the system is trustworthy again for the people who depend on it — and how many other flows stayed up while we fixed this one. If recovery always means a hero session and a silent queue, the product is still selling the happy path.

What this means on the ECORPA case

ECORPA has to be honest about portals it does not own. The personal site is where I write the design lesson. The company site is where the product promise lives. Different surfaces, same allergy to theater — more on that split in why tools lives apart from ECORPA. If you automate on top of someone else's UI, write down what you will absorb, what you will never promise, and what observation would make you unship the happy-path claim. Then build for Tuesday.