The Exception That Swallowed the Queue
A claims process uses a main page that calls a sub-page to submit each claim. The sub-page has a Recover stage around the portal submission and a Resume stage that returns to the main page. During a pilot, the portal began returning a session-expired page for about 12% of claims. The bot did not raise a business exception; instead, it logged the claim as submitted and moved on. Later, 60 claims were found missing in the portal. The team's exception block catches all errors, writes a generic message to the queue item, and marks the item as completed. The process has no distinction between system exceptions and business exceptions, and the queue is configured with a maximum retry of 0.
1. Explain why the session-expired condition was treated as success, and identify the two design defects that allowed 60 claims to be lost.
Read the worked answer
The Recover stage catches errors thrown by the submission stage, but a session-expired page is not an error from the automation's point of view - the page loaded, so no exception was raised. The bot then continued as if submission had succeeded. The exception block's catch-all behaviour compounded this: any error that was raised was written as a generic message and the item was marked completed, so failures were recorded as successes.
Defect one: no positive confirmation of success. The process should verify a specific post-submission element (a confirmation number, a status change) and raise a business exception if it is absent. Absence of an error is not evidence of success.
Defect two: exception taxonomy is collapsed. System exceptions (portal down, timeout, session expiry) should be distinguished from business exceptions (invalid claim data, rejected claim). System exceptions should be retried; business exceptions should go to a human review queue. Marking a system failure as completed destroys the retry path and the audit trail. With max retry 0, even a correctly raised system exception would not be retried, so the queue configuration is a third contributing factor.
2. Recommend a revised exception-handling design for this process, including how the queue should be configured.
Read the worked answer
Design the process around three outcomes per claim: success, business exception, and system exception.
Success requires positive confirmation: after submission, wait for and check a confirmation element. If present, mark the item complete and record the confirmation reference.
Business exception: raised when the claim data is invalid or the portal explicitly rejects the claim. Do not retry; route to a human review queue with the rejection reason and a screenshot reference.
System exception: raised on timeouts, session expiry, or unexpected pages. These should be retried. Set the queue's maximum retry to a small number (for example 2) with a retry interval, so transient portal issues resolve without human intervention. After retries are exhausted, the item moves to an exception queue for investigation.
Also add a session-health check before each submission: if the session has expired, re-authenticate rather than submitting into a dead session. Log every outcome with a distinct code so reconciliation can distinguish 'submitted', 'rejected', and 'failed'. Finally, add a daily reconciliation step comparing queue completions to portal records, so silent losses surface within a day rather than at month end.