Sixty Stalled Expense Claims Nine Days Before Close

Contain, recover, then communicate - in that order, and do not rebuild the flow in place before the stalled items are secured.

1. Freeze changes: no further edits to the flow or app until the incident is closed. Snapshot the current flow definition and app version first, so there is a known state to compare against.
2. Quantify: pull the flow run history and the list of submissions from the last seven days. Identify the 60 stalled claims, their submitters, amounts and dates, and check whether any submissions were never persisted at all because the green message fired before the flow ran.
3. Restore the flow: revert to the last known good version or correct the renamed reference, then decide deliberately whether to resubmit the 60 items by triggering the flow for each item rather than asking 60 people to re-key. Reproducing submissions on behalf of users needs finance sign-off and a record of what was done.
4. Fix the false success message: gate the confirmation screen on an actual success response from the flow, and add an error state that tells the claimant what to do. A silent failure with a success message is a data-integrity defect, not a cosmetic one.
5. Communicate proactively: tell the affected submitters and the approvers what happened, what is being done and when they can expect their claim to move. Do this before the service desk escalates it.
6. Report to finance leadership with the count, dollar exposure and the plan, since close is in nine days and the settlement timing matters.

The failure was a boundary and integration test that was never run, using one happy-path case with a trivial amount. A risk-based matrix would have caught it.

• Boundary values on the new rule: $1,999.99, $2,000.00 and $2,000.01, plus a claim with a different currency if supported. The single $38 test never entered the branch that was changed.
• Role matrix: claimant, first approver, second approver, delegate, approver out of office, approver who has left. Each role exercised end to end at least once.
• Negative and recovery paths: rejection and resubmission, attachment too large, duplicate submission, claimant editing after submission, and a flow failure mid-approval. Confirm the UI shows an error rather than a success.
• Integration check after any schema change: renaming a column is a breaking change. The test plan should explicitly include a post-rename verification of every flow and screen that references that column.
• UAT with real users: two or three finance approvers and two claimants run scripted scenarios in a non-production environment and sign off in writing, including on the boundary cases.

For the fix itself: test in a developer environment with representative data, not the analyst's own account in production. Keep a regression checklist of the ten most critical scenarios and run it on every release - the cost is an hour, and it is the cheapest control available to a citizen developer.

Before close, put in place the minimum that prevents a repeat: a developer environment, a solution, and a change freeze window around close.

• Environments: a developer environment for the analyst and the existing production environment. A full test environment can follow, but two environments is achievable in days and ends live editing.
• Solution packaging: move the app and flow into a solution and export it before and after each change. Managed imports to production give a clean upgrade path; and exporting the previous version gives an actual rollback instead of a rewrite.
• Connection references and environment variables: so promotion does not require hand-editing connections, which is where many citizen-developer deployments break.
• Change freeze: no changes to the app or flow from two business days before close until close is complete, except a documented emergency fix with finance approval.
• Post-deployment smoke test: three claims at $50, $2,000 and $5,000 submitted by real test accounts and traced through to approval before the change is declared live.

Can wait: a dedicated UAT environment, automated regression tooling, and a formal service management integration. Those matter, but they take weeks and would delay the fix.

Also raise to IT and the center of excellence: this app is now a finance system of record for approvals. It needs a named business owner, an entry in the app inventory, and a support route that is not the service desk discovering it during an incident.