The rep left, and nobody could approve his orders

Your state head opens his approvals on Monday morning. Five orders are waiting, four of them raised the same day for one dealer in his own territory. He taps approve on the first and the app tells him the order is outside his team. He tries the second. Same answer. Five orders, five refusals, all of them sitting in his own pending list.

The rep who took those orders had left the company in July. That is the whole story, though it took a day to prove, and it was not just his story.

When we ran the same check for every manager in the company, 143 of the 1,170 pending orders that a manager could see were refused in the same way. Fifty-one pending orders across nineteen departed reps had nobody who could approve them. And 663 dealers were still on the books of somebody who had left, so the problem would come back every time a rep resigned.

What was actually going on

The company is a crop-nutrition manufacturer, about 5,500 dealers ordering through 26 depots, with a field sales team arranged in four tiers. A manager may approve an order if the rep who took it sits somewhere below him in the reporting tree. Two parts of the system ask that question. The pending list asks “who is under me” and includes people who have left. The approve button asks the same question and leaves them out.

So a departed rep’s orders stayed visible to his manager, because the list still counted the rep as part of the team, and stayed unapprovable, because the check did not. Nothing was wrong on either screen taken alone. The two disagreed about who counts.

There was a second, smaller disagreement underneath. The list looked at the dealer’s current rep; the approve check looked at the rep recorded on the order. Those two drift apart whenever a dealer is reassigned.

The first hour went on the server logs, and they were not much help: 549 approval calls, two refused, and neither of the two was his. His own attempts had already aged out of the retained logs. Rather than guess, we replayed the approve check’s own question against the live database for each of his five pending orders. All five failed it, and all five carried the rep who had left on 22 July.

The rule that makes this permanent

Our first note that day called the 663 dealers a clean-up job. The client corrected it, and the correction is the important part. A dealer’s book never moves off the rep who held it, and an order never moves off the rep who took it. Both stay pointing at the original person for ever, so that who added an order, and when, can always be read off the record. Reassigning would silently credit years of orders to someone who never took them.

That is a sound rule. It also means departed reps keep accumulating orders indefinitely, so the approval path has to keep departed staff in the tree permanently. This is not a stopgap.

What we changed

A dedicated approval scope: the same tree the pending list walks, departed staff included, and accepting either the rep on the order or the rep on the dealer. The other tree query, which the field-activity module shares and which rightly excludes departed staff, was left alone.

Before deploying, we ran the old scope and the new one against every one of the 167 managers on production. Of 1,170 pending orders visible to a manager, 143 were refused before and none after, and no manager gained an order outside his own reporting tree. On the test system, the state head who reported it approved his blocked order and was still refused an order from another state head’s territory. On production, the stuck order was approved by its real manager six seconds after the restart.

The rule was written at the top of the function and in the handover notes, because anyone “tidying” the approval scope back to the shared query would re-break approvals across the company and nothing would tell them.

What it did not fix

The handover feature, the screen an admin uses when somebody leaves, does exactly what the rule forbids: it moves the dealer book to the successor. Either that step has to go or the rule is narrower than stated. We put the conflict to the client rather than picking a reading.

And on the way through we found that the portal’s own endpoint for changing an order’s status has no authorisation check at all. It was logged, not fixed, in this piece of work.

The mechanism

Two recursive queries answered “who reports to me, and who reports to them”, each with its own filter on deleted staff. The list’s version would also spin for ever if a reporting chain ever looped back on itself; the new scope carries the path it has walked and stops.

Where this ends up

Sazinga Field keeps a departed rep’s orders approvable by the manager above him, because in a field-sales business the person who took the order and the person who approves it are rarely the same person for long.