When the portal changes, what should happen

There are two ways automation can respond to a changed portal. It can stop and say what it hit, or it can carry on and report success while doing nothing useful. The second is the expensive one, because the cost is not the failed run. It is the two weeks before anyone notices, and the statements, claims or submissions that piled up behind it.

So the property to insist on, from any tool and from any script your team already runs, is that a run either completes and leaves proof, or reports clearly that it did not and names what stopped it. Everything below is how you make that real.

"Completed" is not a status a tool should be allowed to self-assess. Define it per task, in terms of something that exists afterwards:

• Carrier loss run. The PDF is in the folder and carries a recent date.
• Payer claim status. The recorded status matches what the portal displays.
• Supplier statement pull. The statement list contains the new invoice number.

Two signals beat one. Pair something on the page, a specific label or confirmation text, with something in the world, the file that got downloaded or the row that got written. A run that saw a success message but produced no file has not done the work, and only the second signal catches that.

"It broke" is not actionable. Every stopped run should produce the same small set of facts, so they can be sorted, counted and searched later rather than read one at a time:

• Which task, and which step inside it.
• When it stopped.
• What the portal did, in plain words.
• Whether a portal change is suspected.
• A screenshot or equivalent evidence.
• What the operator should check first.

The single most useful field is the distinction between a business exception and an application exception. A missing policy number in your own spreadsheet is a data problem your team fixes. A submit button that no longer exists is the portal changing under you. They go to different people and they mean different things about whether the automation is healthy, and a log that blurs them makes the weekly review useless.

The alert that goes out should carry the task, the step, whether drift is suspected, and one requested action: log in, confirm whether the form changed, and reply either "business as usual" or "portal changed" with details. Say explicitly that the next run stays paused until someone answers. An alert without that line gets read and not acted on.

The cheapest detection is a pre-check. Before the run does anything that matters, confirm the page it expects is the page in front of it: the heading is there, the button it needs exists, the fields it fills are present. If the pre-check fails, skip the task and raise the exception. You have then spent five seconds instead of submitting a form into a layout that changed.

Where a portal gives you nothing reliable to anchor on, a screenshot comparison against a known-good baseline will catch a major redesign, which is the change most likely to break everything at once.

The general rule for whoever maintains the checks: anchor on what a person sees. Headings, button names, field labels. Those survive a redesign more often than the underlying page structure does, and when they change, they change visibly, which means the exception message can say something a human understands.

Automation should hand off rather than guess. Write the triggers down in advance:

• A portal change is suspected.
• A business exception appears that needs judgment, like missing patient or policy information.
• The same portal fails repeatedly inside one day.

Then give operators a short checklist so the review is consistent. Log in, go to the screen, confirm whether the layout, labels or required fields changed, compare against the last successful run, and if something moved, capture a screenshot and note what moved and what the new labels are. Close by marking it either a portal change or a data issue.

That last step is what turns individual incidents into a pattern you can act on. Ten tickets marked "portal changed" against one payer is a different conversation than ten scattered data problems.

A single sheet, reviewed weekly, is enough. Per task: the portal, how many runs in the last thirty days, how many stopped, how many were flagged as suspected drift, how many needed operator review, how long triage took on average, and who owns it.

Two notes on what to track. Time to triage is the number that matters most, because it is the gap between something going wrong and anyone knowing, and it is the one you directly control. And resist writing a target completion percentage into the sheet. A rate computed across different portals with different volumes mostly measures which portal was busiest, and once a threshold exists it becomes a number people defend rather than investigate. Count the exceptions and read their reasons instead.

The operations leader responsible for the portal work, not engineering.

The operator logs the exception with evidence. The operations lead decides whether to correct the task description, move the work, or run it by hand this cycle. Engineering gets involved only when the change needed sits outside the portal. Keeping the decision with the people closest to the work is what keeps the response measured in hours rather than sprints.

If your team maintains its own scripts, everything above is work you have to build and keep building, and the portal will keep changing whether or not you have time that week.

Rindler is built so that portal drift produces an exception rather than a false success. You describe the task the way you would explain it to a new hire, and a run either finishes or tells you what stopped it, in terms an operator can act on. That does not make portals stop changing. It makes the change visible on the day it happens instead of at the end of the month.

It is also reasonable to keep existing automation for the stable internal systems where it already works, and move only the portal-facing work, which is the part that breaks.