Vendor portal update causes intermittent invoice failures
An accounts payable shared-service center uses Pega Robotics to enter 1,200 invoices per day into a vendor portal. Three unattended robots run concurrently on separate virtual machines. After the vendor's quarterly release, 12% of invoices fail with 'element not found' on the Save button. The portal now renders the Save button with a dynamic ID that changes each session, and it displays a confirmation modal only when the invoice amount exceeds $10,000, which is 8% of volume. The automation uses a two-second fixed wait after clicking Save and a CSS selector copied from the old page. Robots also reuse the same portal session for up to 45 minutes, but the vendor enforces a 20-minute idle timeout. Logs show failures cluster after 18 minutes of session age and on high-value invoices. The team's first proposal is to increase the fixed wait to ten seconds and add a retry loop. Month-end volume will double next week.
1. How would you triage the failures before changing the automation?
Read the worked answer
Before changing waits, segment the 12% failures by invoice amount, session age, VM, and time of day. If failures concentrate on invoices above $10,000 and after 18 minutes, the modal and the 20-minute timeout are more likely than a simple slow page. Reproduce with one robot and capture the DOM before and after Save, screenshots, runtime logs, and the vendor release notes. Check whether the Save button's dynamic ID is the only change or whether the modal introduced a new frame. Compare a high-value and low-value invoice in the same session. Also review concurrency: three robots on separate VMs should not share a browser session, but confirm. Build a small test harness that runs ten low-value and ten high-value invoices with session age controlled. The goal is to prove which hypothesis explains each failure mode. Increasing the wait would confound the test and may hide the modal issue. Record failure signatures so later fixes can be verified.
2. Propose a robust redesign of the Save interaction and session handling.
Read the worked answer
Re-interrogate the Save button using stable attributes: visible text, adjacent label, relative position, or a parent container, with matching rules that tolerate dynamic IDs. Add an event-based wait for either the confirmation modal or a success state, not a fixed sleep. For invoices above $10,000, branch to handle the modal: verify amount, click the correct confirmation, and wait for the posting reference. For lower-value invoices, wait for the direct success message. Handle the session timeout explicitly: detect the login page or timeout message, re-authenticate with credentials from the vault, and before resubmitting check whether the invoice was already posted using the invoice number. That idempotency check prevents duplicates. Cap retries at two for transient errors and route exhausted cases to an exception queue with evidence. Renew sessions proactively before 20 minutes or use a session-per-invoice model if performance allows. Log the posting reference for reconciliation.
3. How should you respond to the team's proposed ten-second wait and retry loop?
Read the worked answer
Reject the ten-second wait and retry loop as the primary fix. A longer wait slows every invoice and still fails when the modal appears or the session has expired. A retry loop without an idempotency check can double-post high-value invoices, which is a financial control failure. Retries also increase load during month-end, exactly when the vendor portal is least stable. If a retry is used at all, it should be limited, triggered only by a classified transient error, and preceded by a check that the prior attempt did not succeed. The ten-second wait might be acceptable as a temporary containment measure only if it is paired with monitoring and a rollback plan, but it does not address the dynamic selector or the modal. I would explain the duplicate-payment risk to the team and propose the robust redesign before volume doubles. If month-end cannot wait, run a controlled pilot on low-value invoices while the modal and session fixes are completed.