[Recovery and escalation]
Portal blockers are not one problem. They include CAPTCHA, MFA, OTP codes, popups, human review points, and ambiguous browser states. Ramain handles them as recoverable workflow events rather than treating every blocker as a failed automation.
The first layer is the browser provider
Managed cloud browsers can be launched with CAPTCHA-solving capabilities. This handles common page-level challenges before the workflow has to escalate.
If the portal requires user-specific input, the workflow system has explicit capabilities for OTP polling, human-in-the-loop browser handoff, and agent prompts.
Escalation is part of the graph
The workflow editor includes block capabilities for OTP and human review. An Email Poll Agent can retrieve emailed codes, while a Human Review Agent can pause and ask a person to operate or confirm the live browser.
That means blockers are modeled as durable workflow nodes instead of being buried inside brittle exception handling.
What gets logged
Run statuses distinguish waiting, recovering, fallback, completed, recovered, failed, and terminated states. OTP progress and review decisions are carried into the UI so the operator can see why a run paused.
The goal is not to pretend every portal can be fully automated. The goal is to keep the workflow honest and recoverable.
Ramain treats blockers as workflow states. Some can be handled automatically, and the rest can pause for the right human or OTP input without losing the run.
